Migracja bazy powinna paść jeżeli nie jest w stanie skonwertować danych

[cameel]

Propozycja:

Migracja nie powinna próbować ad-hoc łatać problemów w danych. Jeżeli nie jest jednoznacznie określone jako skonwertować każdy wiersz danych do nowego schema, najbezpiecznieszym podejściem jest zwrócenie błędu.

• Przykład: mamy model Osoba z polem wiek, którego wartość musi być większa lub równa 13. Chcemy zmienić pole tak, aby miało ograniczenie NOT NULL. Jeżeli istnieją jakiekolwiek wiersze z wartością NULL w polu wiek, migracja nie powinna na siłę próbować wstawić w to pole wartości domyślnej (np. 13). Nie powinna też usuwać tych wierszy. Jeżeli nie ma reguł biznesowych, które mówiłyby skąd wziąć brakujące dane, migracja powinna po prostu zakończyć się błędem.

  Ostateczne rozwiązanie problemu może jak najbardziej wymagać wstawienia wartości domyślnej lub usunięcia wiersza, ale ta decyzja może być inna w każdej sytuacji i nie powinna być podejmowana bez przeanalizowania sytuacji. Zwrócenie błędu jest najbezpieczniejszym rozwiązaniem, bo w optymistycznym przypadku problem w ogóle nie wystąpi, w pesymistycznym błąd zwróci nam na niego uwagę. Zakamuflowanie problemu jest najgorszym wyjściem, bo prowadzi do nieodwracalnej modyfikacji danych.

[Jakub89]

👍

[rwrzesien]

👍