In meiner Anwendung hat eine account
verschiedene eindeutige Meldungen (message_templates
), die den Benutzern angezeigt werden müssen. Zum Beispiel können sie in einem Konto, wenn ein neuer Beitrag erstellt wird, "Danke für das Erstellen des Beitrags" anzeigen. und ein anderer Account möchte vielleicht sagen "Der Beitrag wurde erfolgreich erstellt!".Schienen: anwendungsabhängige Daten pflegen
Es gibt eine festgelegte Anzahl dieser In-App message_templates
, die nur zu bestimmten Zeiten ausgelöst werden. Daher wird jedes Konto die gleiche Nummer haben, nur unterschiedliche Werte.
account = Account.create!
MessageTemplate.create(account: account, slug: "post_created_thank_you", body: "Thank you for creating the post!")
...
# Can change the body column but nothing else.
def PostsController < ApplicationController
def create
# create the post...
@thank_you_message = current_account.message_templates.find_by(
slug: "post_created_thank_you"
)
end
end
Wie ich Funktionen der Anwendung bin fügte aber hinzu, finde ich, dass manchmal möchte ich einen anderen message_template
hinzufügen und ich brauche diese Vorlage, um sicherzustellen, wird für alle Girokonten erstellt.
Ich habe über die Verwendung von Rails-Migrationen nachgedacht, um sicherzustellen, dass jeder die account
die verschiedenen message_templates
hat, aber Migrationen sind wirklich für DB-Schemaänderungen und nicht für Anwendungsdatenänderungen.
Ich schaute auch auf rake db:seed
, aber das ist wirklich für das Seeding der DB zunächst nicht für die Wartung von Updates.
Eine Lösung besteht darin, Rake-Aufgaben zu erstellen, die ich manuell ausführe, wenn ich eine neue Vorlage anlege. Scheint etwas klobig.
Was ich wirklich möchte, ist Migrationen für Daten gebaut. Dies scheint ein häufiges Problem zu sein, gibt es eine Standardmethode, dies zu implementieren? Sonst werde ich wahrscheinlich ein Juwel schreiben, das Migrationen für Daten implementiert.
Ich weiß, dass ich Daten in die Migrationen selbst einbringen kann, aber ich höre viele Leute empfehlen, dies nicht zu tun: Migrationen haben jetzt Geschäftslogik in ihnen (dh Daten) und Sie können diese Migrationen nicht entfernen/quetschen ohne zu brechen Core-App-Funktionalität. Ich spiele damit, genau das zu tun, was Sie mir empfohlen haben, aber ich wollte zuerst sehen, ob es einen saubereren Ansatz gibt. –
Egal, was Sie tun, Sie werden immer noch Daten haben ... und es muss immer noch in einer Migration ausgeführt werden, um es in Ihre prod db zu bekommen. Jede andere Lösung ist nur eine Verschleierung dieser Tatsache. Es gibt andere Möglichkeiten, den Kuchen zu schneiden ... aber sie alle laufen auf "Ich führe eine Migration und es läuft etwas, das Daten in die Datenbank legt" :) –