Jest to rodzaj kontynuacji tego pytania: Czy Rails Migrations może być używany do konwersji danych?
Jeśli pracuję nad oddziałem, kiedy jestponownie zintegrowane i udostępnione do produkcji, zmieni schemat bazy danych dość drastycznie. Jaki jest najlepszy sposób na przekonwertowanie wszystkich danych w produkcji na nowy format?
Prostym przykładem może być kolumna numeryczna, którą chcemy zmienić na tekst i wykonać kilka konwersji danych. Następnie chcemy usunąć starą kolumnę.
Zostałem poinformowany, że nie należy manipulować danymi w migracjach, ale raczej tworzyć dla nich rake. Czy istnieje mechanizm umożliwiający wykonywanie zadań rake'owych w porządku wraz z migracjami?
W tej chwili jedynym rozwiązaniem, jakie mogę wymyślić, jestspakuj wszystkie migracje, które upuszczają nieistniejące kolumny do drugiej kolekcji. Uruchom pierwszy zestaw migracji, które dodają nowe tabele. Uruchom zadania rake, a następnie uruchom drugi zestaw migracji. To nie wydaje mi się idealnym rozwiązaniem dla mnie i może łatwo pójść nie tak.
Odpowiedzi:
2 dla odpowiedzi № 1Migracje są właśnie dla tego rodzaju rzeczy. Konwersja danych w bazie danych dla nowej wersji aplikacji, ze zmianą schematu lub bez niego, powinna być migracją. Jest to gwarancja, że nowe zmiany zostaną wprowadzone w produkcji przed uruchomieniem nowej wersji aplikacji.
Kiedy pracujesz w branży, po prostu stwórz anowa migracja, która utworzy nowy plik z oznaczeniem czasu. Po scaleniu z gałęzi wydania plik zostanie po prostu skopiowany. Ze względu na znacznik czasu migracje będą (prawdopodobnie) wykonywane we właściwej kolejności.
Jeśli konwersja, którą wykonujesz, będzie nadal wykonywana od czasu do czasu, powinieneś użyć zadania Rake.