Aktualizacja schematu doktryny lub migracje Doctrine

Question

Jakie są praktyczne zalety migracji Doctrine po uruchomieniu aktualizacji schematu?

Bezpieczeństwo?

orm:schema-tool:update poleceń (doctrine:schema:update w Symfony) ostrzega

Ta operacja nie powinna być wykonywana w środowisku produkcyjnym.

, ale dlaczego tak się dzieje? Oczywiście, może usuwać dane, ale także może migrować.

Elastyczność?

Pomyślałem, że mogę dostosować moje migracje, aby dodać takie rzeczy, jak domyślne ustawienia kolumn, ale to często nie działa, ponieważ Doctrine zauważy rozbieżność między schematem i kodem w następnej kolejności i przejmie twoje zmiany.

Answer 1

Kiedy używasz schema-tool, nie historia modyfikacji bazy danych są przechowywane, a także w produkcji/środowiska pomostowego jest to duży minus.

Załóżmy, że masz skomplikowaną strukturę bazy danych w projekcie na żywo. A w następnym zestawie zmian musisz jakoś zmienić bazę danych. Na przykład telefony kontaktowe użytkowników muszą być przechowywane w innym formacie niż kolumny VARCHAR, ale trzy SMALLINT dla kodu kraju, numeru kierunkowego i numeru telefonu.

Cóż, nie jest tak trudno znaleźć zapytanie, które pobrałoby bieżące dane, oddzieli je na trzy wartości i wstawi je z powrotem. Wtedy zaczynają się migracje: możesz tworzyć nowe pola, a następnie transformować i ostatecznie usunąć pole, w którym przechowywano dane.

I jeszcze więcej! Można nawet opisać proces cofania (migracja down), kiedy trzeba cofnąć zmiany wprowadzone w migracji. Załóżmy, że ktoś gdzieś polegał w dużym stopniu na formacie pola VARCHAR, a teraz, gdy zmieniłeś strukturę, jego fragment kodu nie działa zgodnie z oczekiwaniami. Tak więc uruchamiasz migration:down, a wszystko zostanie przywrócone. W tym konkretnym przypadku wystarczy, że przywrócisz starą kolumnę VARCHAR i połączysz wartości z powrotem, a następnie usuniesz te pola.

Narzędzie do analizy Doctrine w zasadzie wykonuje większość pracy za Ciebie. Kiedy zmieniasz swój schemat, generuje on wszystkie niezbędne up i down, więc jedyne, co musisz zrobić, to obsłużyć dane, które mogą zostać uszkodzone podczas migracji.

Migracje to także coś, co daje innym programistom w zespole wiedzę na temat tego, kiedy należy zaktualizować ich schematy. Tylko z schema-tool, twoi koledzy z drużyny będą musieli uruchomić doctrine:schema:update za każdym razem, gdy będą ciągnąć, ponieważ nie będą wiedzieli, czy schemat naprawdę się zmienił.

Podczas korzystania z migracji zawsze widać, że w folderze migracji są pewne aktualizacje, co oznacza, że ​​trzeba zaktualizować swój schemat.

Answer 2

Wydaje mi się, że rzeczywiście przyłożyłeś go do Bezpieczeństwa. Migracje umożliwiają powrót do innego stanu tabeli (tak jak w przypadku kontroli wersji Git). Za pomocą polecenia aktualizacji schematu można aktualizować tylko tabele. Nie ma logu do powrotu w przypadku awarii z już zapisanymi danymi w tych tabelach. Nie wiem dokładnie, ale czy migracja nie zapisuje również danych z odpowiedniej tabeli, która jest aktualizowana? Moim zdaniem byłoby to niezbędne, w przeciwnym razie nie ma żadnego powodu, aby z nich korzystać.

Tak, osobiście uważam, że głównym powodem korzystania z migracji w środowisku produkcyjnym jest bezpieczeństwo i być może odrobina elastyczności. Bezpieczeństwo będzie tu zwycięzcą, myślę, że :)

Mam nadzieję, że to pomoże.

edit: Oto kolejna odpowiedź z odniesieniami do docs Symfony: Is it safe to use doctrine2 migrations in production environment with symfony2 and php