Migrowanie danych

Powiedzmy, że chcemy zmodyfikować naszą aplikację, która zapisuje dane w jednej tabeli w bazie danych. Modyfikacja polega na tym, że chcemy dodać nową kolumnę do tej tabeli, która będzie zawierać jakieś przeliczone wartości.

(Tak naprawdę nie ma to znaczenia, jak istotna jest to zmiana, czy to dodanie kolumny, czy to zbudowanie całego innego storage na read-model, sytuacja pod kątem zachowania aplikacji będzie podobna)

Przy takich zmianach potrzebujemy minimum 2 flag:

• Jedna flaga (migracyjna) pozwoli włączyć dodatkowe operacje, jakie mają dziać się przy zapisie danych. (np. zapis do dodatkowej kolumny, zapis do dodatkowej tabeli, zapis do innego storage).
• Druga flaga (developerska) pozwoli uruchomić kod pobierania danych w nowy sposób.

W obu przypadkach można wykorzystać technikę Branch By Abstraction.

Gdy nasz nowy storage jest już gotowy, możemy zacząć migrować i zbierać nowe dane. Możemy to zrobić, zanim część systemu odpowiedzialna za prezentację tych danych będzie gotowa. Często zdarza się, że warto zebrać te dane i zmierzyć wydajność systemu, który je prezentuje, zanim udostępnimy funkcję użytkownikowi.

Migracja (lub uzupełnienie) takich danych sprowadza się do dwóch czynności:

• Przełączenie flagi migracyjnej, aby wszystkie nowe zmiany wprowadzone przez użytkownika były zapisywane w nowy sposób.
• Uruchomienie procesu migracji danych, który dokonując stosownych przeliczeń, przeniesie wszystkie "stare" dane.

Na tym etapie prezentujemy dane w stary sposób, ale jednocześnie zasilamy danymi nasz nowy storage.

Gdy część systemu związana z prezentacją danych będzie gotowa, możemy przełączyć flagę deweloperską i zbadać wydajność naszego systemu dla części naszych użytkowników. Jeśli okaże się, że osiągnęliśmy cel, możemy przełączyć flagę wszystkim użytkownikom i usunąć obie flagi z systemu.