rake db: schema: load vs. migrations

171

Tutaj bardzo proste pytanie - jeśli migracje mogą stać się powolne i uciążliwe, gdy aplikacja staje się bardziej złożona, a rake db:schema:loadzamiast tego mamy znacznie czystsze do wywołania, dlaczego migracje w ogóle istnieją?

Jeśli odpowiedź na powyższe pytanie brzmi, że migracje są używane do kontroli wersji (krok po kroku zapis zmian w bazie danych), to gdy aplikacja staje się bardziej złożona i rake db:schema:loadjest używana częściej, czy nadal zachowują swoją podstawową funkcję?

Uwaga:

Z odpowiedzi na to pytanie: rake db:schema:load usunie dane na serwerze produkcyjnym, więc zachowaj ostrożność podczas korzystania z niego.

ruby-on-rails ruby-on-rails-3 migration

— sscirrus
źródło

5

+1 Nigdy nie rozumiałem celu migracji; dlaczego nie tylko kontrola wersji schematu?

— alternatywa

5

@alternative - migracje pozwalają robić inne rzeczy, na przykład jeśli chcesz dodać niepustą kolumnę, możesz sprytnie wypełnić tę kolumnę danymi zamiast używać wartości domyślnej.

— Josh M.

208

Migracje zapewniają zmiany krokowe do przodu i do tyłu w bazie danych. W środowisku produkcyjnym podczas wdrażania należy wprowadzać przyrostowe zmiany w bazie danych: migracje zapewniają tę funkcjonalność z możliwością wycofania w razie awarii. Jeśli uruchomisz rake db:schema:loadna serwerze produkcyjnym, w końcu usuniesz wszystkie dane produkcyjne. Jest to niebezpieczny nawyk.

Biorąc to pod uwagę, uważam, że sporadyczne „załamanie” migracji jest przyzwoitą praktyką. Wiąże się to z usunięciem starych migracji, zastąpieniem ich pojedynczą migracją (bardzo podobną do schema.rbpliku) i zaktualizowaniem schema_migrationstabeli w celu odzwierciedlenia tej zmiany. Zachowaj przy tym ostrożność! Jeśli nie jesteś ostrożny, możesz łatwo usunąć dane produkcyjne.

Na marginesie uważam, że nigdy nie należy umieszczać tworzenia danych w plikach migracyjnych. seed.rbPlik może być użyty do tego, czy zwyczaj natarcia lub wdrożyć zadania. Umieszczenie tego w plikach migracji powoduje mieszanie specyfikacji schematu bazy danych ze specyfikacją danych i może prowadzić do konfliktów podczas uruchamiania plików migracji.

— jesse reiss
źródło

80

dziękujemy za poinformowanie, że rake db: schema: load usuwa wszystkie dane produkcyjne!

— Magne

2

Zamiast zastępować „zwinięte” migracje nową, która naśladuje schemat, napisałem klejnot, który po prostu je usuwa i zachęca użytkowników do użycia, db:schema:loadjeśli próbują uruchomić db:migratenową instalację. @ clear_migrations

— Yarin

prawdopodobnie oczywista odpowiedź, ale czy przed pierwszym przejściem do środowiska produkcyjnego zalecamy po prostu usunięcie wszystkich migracji i użycie db.schema jako pierwszej migracji?

— dtc

30

Właśnie natknąłem się na ten post, który był dawno temu i nie widziałem odpowiedzi, której się spodziewałem.

rake db:schema:loadjest świetny, gdy po raz pierwszy wprowadzasz system do produkcji. Następnie należy normalnie uruchomić migrację.

Pomaga to również w czyszczeniu migracji, kiedy tylko chcesz, ponieważ schemat zawiera wszystkie informacje potrzebne do wprowadzenia innych maszyn do produkcji, nawet po wyczyszczeniu migracji.

— ereslibre
źródło

Możesz więc „wyczyścić” swoje migracje, ponieważ nigdy nie musisz ich używać? Brzmi jak dziwne stwierdzenie.

— Abe Petrillo

Nie jest dla mnie jasne, jakie korzyści płyną z db:schema:loadtego, poza skróceniem kilku sekund w całym cyklu rozwojowym. Czy zdarzyło Ci się pracować z aplikacją, której tworzenie trwało dłużej niż 30 sekund? Obecnie pracuję nad aplikacją, która ma błędy w swoich plikach migracji i nigdy nie będzie migrować w górę bez poprawek błędów lub uruchomienia, db:schema:loadco sprawia, że myślę, że schemat: ładowanie dotyczy sytuacji, gdy coś poszło nie tak w związku z rozwojem aplikacji.

— Ninjaxor,

Kolejnym argumentem, który chciałbym przedstawić za utrzymaniem migracji, jest to, że główny zespół rails kieruje użytkowników do instead of editing schema.rb, please use the migrations feature. Jeśli więc db:schema:loadkorzystasz z automatycznie wygenerowanego pliku, którego migracje nie mają być ponownie generowane automatycznie, w rzeczywistości idziesz drogą ręcznej „edycji” schematu i rezygnacji z migracji. Chciałbym mieć cytat z przewodnika po szynach na ten temat, ale nie omawiają schematu: obciążenie, co zniechęcająco zwiększa moją frustrację przy podejmowaniu decyzji, jak podejść do schematu: funkcja ładowania. = /

— Ninjaxor

Trafiłem na tę stronę właśnie dlatego, że się z tym zgadzam. Z mojego doświadczenia wynika, że kiedy witryna jest już gotowa, dużo bezpieczniej jest użyć migracji, aby ją zmienić. Mimo to komentarze na początku db / schema.rb dokładnie mówią inaczej! (Mam problem na początku każdego projektu, bo zapomniałem umieścić db / schema.rb w .gitignore ...)

— user1251840

@AbePetrillo wow Całkowicie przegapiłem ten komentarz. Oczywiście, że nie, miałem na myśli to, że jeśli chcesz, możesz wyczyścić stare migracje, które zostały uruchomione na wszystkich maszynach produkcyjnych. Przez lata zawsze je trzymałem, ale moje stwierdzenie „pomaga w czyszczeniu migracji, kiedy tylko chcesz” nie oznaczało, że „nigdy nie musiałbym używać migracji”. Tak więc, kiedy wdrażasz nową maszynę, uruchom rake db:schema:loadw przeciwieństwie do rake db:migrate. Od tego momentu możesz rake db:migrate.

— ereslibre

9

Migracje umożliwiają również dodawanie danych do bazy danych. ale db: schema: load ładuje tylko schemat.

— Shaunak
źródło

6

Ponieważ migracje można cofnąć i zapewnić dodatkowe funkcje. Na przykład, jeśli chcesz zmodyfikować niektóre dane w ramach zmiany schematu, musisz to zrobić jako migrację.

— Jamie Penney
źródło

4

Jako użytkownik innych ORM-ów zawsze wydawało mi się dziwne, że Railsy nie mają funkcji „synchronizacji i aktualizacji”. tj. korzystając z pliku schematu (który reprezentuje cały, aktualny schemat), przejrzyj istniejącą strukturę bazy danych i dodaj / usuń tabele, kolumny, indeksy zgodnie z wymaganiami.

Dla mnie byłoby to dużo bardziej solidne, nawet jeśli być może trochę wolniejsze.

— Dan James
źródło

1

Zadanie migracji bazy danych z danymi z jednego skomplikowanego schematu do innego nie jest czasami banalne. Problem może nie zostać rozwiązany automatycznie, a migracja danych może nie być spójna w jednym kroku. Migracja Railsów jest nadrzędna, a schemat jest zależny. Schemat jest automatycznie odtwarzany przy każdej migracji, ale nie odwrotnie.

— oklas

Własne przewodniki Railsów wyraźnie mówią, że schemajest to master, a nie migracje.

— Drenmi

0

Napisałem już jako komentarz, ale wydaje mi się, że lepiej umieścić komentarze z pliku db / schema.rb tutaj:

# Note that this schema.rb definition is the authoritative source for your
# database schema. If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It's strongly recommended that you check this file into your version control system.

Właściwie z mojego doświadczenia wynika, że lepiej jest umieścić pliki migracji w git, a nie plik schema.rb ...

— user1251840
źródło

0

rake db:migrateskonfigurować tabele w bazie danych. Po uruchomieniu komendy migracji, będzie ona szukała w db / migrate / wszelkich plików ruby i wykonywała je, zaczynając od najstarszego. Na początku każdej nazwy pliku migracji znajduje się sygnatura czasowa.

W przeciwieństwie do rake db:migratetego uruchamia migracje, które nie zostały jeszcze uruchomione, rake db:schema:loadładuje schemat, który jest już wygenerowany w db/schema.rbbazie danych.

Możesz dowiedzieć się więcej o poleceniach bazy danych rake tutaj .

— Nesha Zoric
źródło