O samym DoctrineMigrationsBundle słyszał na pewno każdy programista mający styczność z Symfony. Nie chce tutaj tłumaczyć rzeczy oczywistych lub takich, które oficjalna dokumentacja wyjaśnia bardzo dobrze – jeżeli ktoś chce się z nim zapoznać, odsyłam do dokumentacji. W tym wpisie opiszę pewien „smaczek” który mnie ostatnio spotkał, a który powinien uczulić deweloperów na ręczne zmiany w migracjach.
Czysta baza, zero zmian w kodzie, a diff coś pokazuje..
Sytuacja z nagłówka nie zdarza się zbyt często – o ile faktycznie, jeżeli ktoś nie przywiązał zbyt dużej uwagi do tworzenia migracji, mogą zadziać się cuda na projekcie który już mamy postawiony, o tyle sytuacja gdzie klonuje projekt z repozytorium, odpalam wszystkie migrację a
php bin/console doctrine:migrations:diff
pokazuje że chce coś zmienić, mocno mnie zaskoczyła.
Wszystko rozchodziło się o sposób generowania przez bundla nazwy indeksów. Są one generowane na podstawie nazwy kolumny, mimo że pozornie wyglądają na jakieś losowe liczby i cyfry. Wtedy tego nie wiedziałem.
Na świeżym projekcie ze świeżą bazą danych powyższe polecenie tworzyło plik migracji, w którym następowała zmiana indeksu. Wyszukując nazwę „starego” indeksu znalazłem plik migracji. Dopiero analizując historię w Gicie, zauważyłem że nastąpiła ręczna zmiana w migracji – w zapytaniu które miało za zadanie dodać nowy indeks, została zmieniona nazwa kolumny.
Cała struktura bazy była w 100 procentach poprawna. Jednak ze względu na mechanizm rozpoznawania indeksów bundle koniecznie chciał zmienić jego nazwę – co też uczyniliśmy. Oto krok po kroku co zaszło:
1. Została utworzona encja o nazwie „User” wraz z kilkunastoma parametrami, w tym „name” oraz „surname”.
2. W pliku konfiguracyjnym encji został dodany index na parametr „name”
3. Została wygenerowana migracja
4. Kod został zacommitowany
5. Autor zorientował się, że index miał być na innym parametrze – „surname”
6. Plik konfiguracyjny został poprawnie zmieniony
7. W pliku migracji zostało edytowane zapytanie – zmieniono w nim tylko i wyłącznie nazwę kolumny
8. Kod został zacommitowany i pushnięty
W wyniku takiego zachowania każde kolejne wywołanie komendy generującej plik migracji będzie dodawał do niego zapytanie zmieniające nazwę indeksu. Aby wszystko przebiegło poprawnie, krok 7 powinien wyglądać następująco:
7a. Generujemy kolejną migrację ze zmianą nazwy indeksu (najłatwiejsze rozwiązanie które bardzo polecam)
7b. Generujemy kolejną migrację, kopiujemy z niej nazwę indeksu, która zostałaby w nim nadana i edytujemy pierwotną migrację (będzie trochę „czyściej”, ale zmusi innych programistów do postawienia bazy od nowa)
Podsumowanie – o co ten krzyk?
Tak naprawdę nic takiego się nie stało – wystarczyło odpalić migrację którą bundle sam generował i zapomnieć o sprawie, co pewnie zrobiłoby 90% programistów. Tutaj (nie)stety wyszło moje czepialstwo – chciałem zrozumieć dlaczego nie robiąc żadnych zmian takowe się jednak pojawiają. Więc pamiętajcie – aby ktoś sobie nie zadawał tych pytań co ja, sprawdzajcie czy doctrine migrations bundle wygeneruje wam nowy plik migracji po jakiejkolwiek, nawet kosmetycznej zmianie w encji lub innym zapytaniu.