Zarządzanie zmianami w bazie danych podczas aktualizacji modułów w PrestaShop

Jest pewien konkretny bilet wsparcia, którego nauczyłem się obawiać. Sprzedawca aktualizuje moduł; wydaje się, że przechodzi, a potem coś przestaje działać. Nigdy cały sklep. Jedna strona kontrolera PrestaShop nie działa, albo wartość konfiguracji nie chce się zapisać, albo kolumna z listą produktów sama się opróżnia. Kiedy sprawdzam, kod modułu jest w nowej wersji, a baza danych pod spodem nadal w starej.

O tej luce jest mowa w tym artykule. Moduł PrestaShop to nie tylko dostarczony kod PHP, ale także ten kod PHP wraz z tabelami i kolumnami, których PHP oczekuje. Pomiń aktualizację bazy danych PrestaShop, która powinna zostać dodana wraz z wydaniem kodu, a otrzymasz zainstalowany, pozornie działający moduł, który jednak działa nieprawidłowo.

Zrobiłem to sobie nie raz. Poniżej znajdziesz informacje, których się dowiedziałem. Aktualizacje bazy danych modułu PrestaShop, w trudny sposób.

1.0 W jaki sposób aktualizacje modułów PrestaShop faktycznie obsługują bazę danych

W tym kontekście krąży wiele założeń, z których niektóre są błędne.

Upuść nową wersję do /moduły/ a procedura instalacji nie uruchamia się ponownie. Tabele pozostają nietknięte. Co się dzieje zamiast tego: PrestaShop odczytuje moduł Aktualizacja / folder, wyszukuje pliki o nazwie aktualizacja- .php siedząc pomiędzy wersją nagraną i tą zadeklarowaną przez klasę modułu, i uruchamiając je po kolei.

Sklep o wersji 1.9.0 otrzymujący wersję 2.1.0 uruchamia kolejno trzy skrypty.

Z tego wynikają trzy rzeczy i wszystkie trzy mają znaczenie Zmiany w bazie danych PrestaShop.

Wersja w tabeli `module` jest źródłem prawdy. Nie ten z pliku klasy głównej. PrestaShop odczytuje oba. Działa na podstawie tego, który został zarejestrowany i to on decyduje o liczbie skryptów aktualizacji, które zamierzasz uruchomić.

Metoda `install()` jest przeznaczona wyłącznie dla nowych instalacji. Załóżmy, że wersja 2.0 potrzebuje nowej tabeli. Umieść ją w zainstalować() A każdy, kto od razu przejdzie na wersję 2.0, jest objęty ubezpieczeniem. Sklep, który korzysta z wersji 1.9, nie otrzyma niczego, ponieważ jego instalacja działała rok temu i już nigdy nie działa.

Jedna porażka zatrzymuje wszystko. Powrót fałszywy Z funkcji aktualizacji dzieją się trzy rzeczy: PrestaShop zatrzymuje się, rejestruje, która wersja się zepsuła i wyłącza moduł. Nie ma możliwości przejścia do następnego skryptu. To celowe, ale oznacza, że ​​połowicznie wprowadzona zmiana schematu powoduje wyłączenie, a nie uszkodzenie.

włączanie automatycznej aktualizacji modułów Strona określa zasady nazewnictwa plików. Przeczytaj ją raz, poprawnie, a nie z pamięci.

Pułapka nazewnictwa funkcji aktualizacji

To kosztowało mnie popołudnie. Albo moduł_aktualizacji_2_0_1 or upgradeModule201 Działa jako nazwa funkcji, a PrestaShop sprawdza obie. Przed dołączeniem pliku sprawdza również, czy któraś z tych nazw już istnieje. Po jej znalezieniu plik zostaje oznaczony jako duplikat i pominięty.

Ludzie kopiują stary skrypt aktualizacji jako szablon i właśnie tak się tu dostają. Nazwa w nim zawarta nigdy się nie zmienia. Nic się nie aktualizuje, a komunikat o błędzie niewiele powie.

Migracja bazy danych PrestaShop 2.0: co idzie nie tak w prawdziwych sklepach

Wszystko to wydarzyło się w sklepach, w których pracowałam.

Zmiany schematu bazy danych PrestaShop, które zmieniają się pomiędzy instalacjami

Wersja 2.0 wymaga nowej kolumny, więc należy dokonać aktualizacji zainstalować() i napisz skrypt aktualizacji. Oba poprawne. Po trzech wersjach ktoś zmienia nazwę folderu modułu lub sprzedawca ponownie instaluje. W niektórych instalacjach install() utworzył tę kolumnę. W innych ścieżka aktualizacji tak. Dwie definicje, różniące się od siebie, teraz obejmują obie.

Definicja znajduje się zatem w jednej metodzie, którą wywołują obie ścieżki. Zmiany schematu bazy danych PrestaShop nie mogą się zmieniać, jeśli istnieje tylko jedna metoda.

Uaktualnij skrypty, które zakładają czysty punkt początkowy

ZMIEŃ TABELĘ … DODAJ KOLUMNĘ W przypadku kolumny, która już istnieje, zgłaszany jest błąd, funkcja zwraca wartość false, a moduł zostaje wyłączony. Przerwij poprzednią aktualizację, przywróć częściową kopię zapasową, dwukrotnie zsynchronizuj z serwerem przejściowym: wykonaj dowolną z tych czynności i jesteś na miejscu.

Każda zmiana schematu, którą teraz wprowadzam, jest najpierw sprawdzana. Dodanie kolumny oznacza POKAŻ KOLUMNY wcześniej, utworzenie tabeli oznacza POKAŻ TABELE, indeks oznacza POKAŻ INDEKSKilka linijek i skrypt przetrwa drugie uruchomienie. To ważne, bo baza danych obcej osoby może znajdować się w dowolnym stanie. Jest… JEŚLI NIE ISTNIEJE zarówno MySQL i MariaDB, ale tylko w przypadku niektórych operacji, więc jawne sprawdzenie jest skuteczniejsze.

Multistore: wiersze konfiguracji napisane tylko dla jednego sklepu

Cichy i nieprzyjemny, ten. W nowej wersji pojawia się ustawienie dla każdego sklepu. Domyślny wiersz został utworzony przez skrypt aktualizacji, przetestowany przez programistę i wszystko wygląda dobrze. Ale jeden wiersz został napisany, niezależnie od tego, który sklep był w kontekście, a sprzedawca uruchamia cztery.

W trzech sklepach brakuje tego elementu. W zależności od tego, jak kod to odczyta, otrzymasz powiadomienie PHP, pustą wartość traktowaną jako rzeczywiste ustawienie lub puste miejsce w miejscu, gdzie powinna być cena. dokumentacja multistore Obejmuje reguły kontekstowe. Zapętla każdy identyfikator sklepu w dowolnej aktualizacji dotyczącej konfiguracji lub danych dla konkretnego sklepu.

W przypadku instalacji w pojedynczym sklepie błąd ten jest niewidoczny.

Blokady ALTER TABLE w dużych tabelach katalogowych

Dodanie kolumny do tabeli zawierającej 400 000 wierszy nie jest natychmiastowe. W zależności od operacji, wersji MySQL i silnika bazy danych, cała tabela może zostać skopiowana. W działającym sklepie, w godzinach handlowych, blokada ta działa na tyle długo, że klienci mogą to zauważyć.

Dlatego sprawdzam rozmiar tabeli przed napisaniem migracji. Jeśli jest duży: okno konserwacji lub restrukturyzacja, aby uniknąć przebudowy.

Klucz konfiguracyjny bez wartości domyślnej

Ten, który widzę najczęściej w modułach innych osób, i nie ma w nim żadnej tabeli.

Dodajesz ustawienie w nowej wersji. Formularz administratora je odczytuje. Podobnie kontroler frontowy. Oba zostały napisane na komputerze, na którym strona ustawień została już co najmniej raz zapisana. Klucz istnieje i wszystko wygląda poprawnie. Wprowadź to, a każda istniejąca instalacja będzie odczytywać ustawienia. Konfiguracja klucz, którego nikt nigdy nie napisał.

To co wraca to fałszywy. Twoja wartość domyślna nigdy się nie pojawia, ani pusty ciąg znaków, który można by przynajmniej sprawdzić. Stamtąd jest on używany jako liczba lub przekazywany do funkcji, która wymaga ciągu znaków. Tryb debugowania jest wyłączony i często uchodzi to na sucho: sprzedawca widzi stronę, która jest lekko błędna i nie zwraca na to uwagi. Tryb debugowania jest włączony i pojawia się jako powiadomienie lub błąd typu. Właśnie dlatego do ciebie dociera komunikat „moduł psuje się w trybie debugowania”, podczas gdy tryb debugowania jest jedyną uczciwą stroną zaangażowaną w ten proces.

Ten sam kod, z wpisanymi wartościami domyślnymi i bez nich.

Rozwiązanie jest nudne. Każdy nowy klucz konfiguracyjny ma zapisany swój domyślny klucz w skrypcie aktualizacji, dla każdego sklepu, wraz z kodem, który go odczytuje. Należy go również traktować z dystansem, ponieważ nie można mieć pewności, że aktualizacja się uruchomiła.

Migracja bazy danych modułu PrestaShop a zmiana schematu

Zmiany schematu to łatwa połowa. Trudniejsza połowa to zmiana znaczenia istniejących danych: podzielenie kolumny na dwie, przeniesienie pola CSV do powiązanej tabeli, ponowne zakodowanie statusu.

To właśnie tam widziałem największe zniszczenia. Nieudolna ALTER TABLE Zawodzi głośno; nieudana transformacja danych kończy się sukcesem i generuje nonsens. Migracja bazy danych modułu PrestaShop, która przenosi dane, wymaga zliczenia przed i po, a następnie porównania. Lepiej znaleźć ją w skrypcie aktualizacji niż znaleźć sprzedawcę trzy tygodnie później.

3.0 Najlepsze praktyki aktualizacji modułu PrestaShop, których właściwie broniłbym

Ci, którzy mnie uratowali:

Uczyń każdą migrację idempotentną

Nic nie powinno się zmienić w drugim uruchomieniu, czego nie udało się obsłużyć w pierwszym. Wystarczy pobrać tę właściwość, a cała kategoria problemów z obsługą zniknie, ponieważ stan bazy danych przestaje być czymś, co trzeba najpierw ustalić. Przed zapisaniem surowego kodu SQL do tabel głównych, PrestaShop… notatki dotyczące warstwy bazy danych są warte godziny.

Ostrożna wersja przetrwała drugie przejście.

Rejestruj każdą awarię zamiast bezgłośnie zwracać fałsz

Nagi zwróć fałsz To wystarczy, żeby PrestaShop zatrzymał i wyłączył moduł. Tobie to nie wystarczy. Więc zakończ pracę. Przechwyć to, co się pojawi, i przekaż to do PrestaShopLoggera z dołączoną nazwą i wersją modułu. W przeciwnym razie sprzedawca zgłosi nieudaną aktualizację, a ty będziesz zgadywać.

W PHP 7 i nowszych, złap Błąd jak również Wyjątek. Otrzymasz błąd typu w swoim własnym kodzie migracji i zostanie on dostarczony jako Błąd, więc opiekun obserwuje tylko Wyjątek pozwala mu przejść.

Wspieraj każdą wersję, którą kiedykolwiek wydałeś

Sprzedawca może korzystać z dowolnej wydanej przez Ciebie wersji. Ktoś, kto przechodzi z wersji 1.4 na 3.0, uruchamia wszystkie skrypty pomiędzy nimi, po kolei, więc każdy musi pracować na schemacie, który pozostawił poprzedni. Dlatego stare pliki aktualizacji pozostają w module. Ktoś, kto jest dwa lata do tyłu, nie ma innej drogi naprzód.

Przetestuj na środowisku testowym, a nie na czystej instalacji lokalnej

Nowa instalacja nowej wersji nie dowodzi niczego w kwestii aktualizacji. Zamiast tego: zainstaluj starą wersję, wprowadź realistyczne dane, a następnie zaktualizuj. Również w przypadku multistore, jeśli to obsługujesz.

Jeszcze lepiej: weź kopię prawdziwego sklepu i przeprowadź aktualizację właśnie przez niego. Twoja lokalna instalacja ma czyste dane i cztery produkty, dlatego nic się nie wyświetla. Prawdziwy sklep zawiera niedokończone importy, wiersze pozostawione przez moduł odinstalowany dwa lata temu, kolumny dodane ręcznie przez poprzedniego programistę, katalog na tyle duży, że… ALTER TABLE Trwa chwilę.

Potem czas. Aktualizacja, która wymaga sześciu minut w stosunku do rzeczywistych danych, jest lepiej znana podczas rezerwacji okna konserwacyjnego niż o jedenastej w piątek.

Zrób kopię zapasową przed zmianami schematu i powiedz o tym

Żadna migawka tabel nie jest wykonywana przed aktualizacją modułu. Ani przez PrestaShop, ani przez nic innego. Jeśli więc sprzedawca nie ma kopii zapasowej, a migracja zatrzymuje się w połowie transformacji danych, dane te znikają. Należy to zgłosić w dzienniku zmian, zamiast odkrywać to na bieżąco.

Odzyskiwanie nieudanej aktualizacji bazy danych PrestaShop

Aktualizacja nie powiodła się w działającym sklepie; moduł został wyłączony. W przybliżeniu taka kolejność:

Dowiedz się, która wersja nie powiodła się. To się zapisuje i jeśli napisałeś komunikat w dzienniku, on też tam będzie. Dzięki temu będziesz wiedział, który skrypt otworzyć i jakie zmiany zostały wprowadzone przed jego zatrzymaniem.

Sprawdź rzeczywisty schemat, a nie numer wersji. Wszystko moduł Tabela wie, co zapisał ostatni udany upgrade. Prawdziwe tabele to te, w których znajduje się odpowiedź, porównywane z tym, co próbował zrobić nieudany skrypt.

Naprawiaj do przodu, nie do tyłu. Cofnięcie numeru wersji jest kuszące i zazwyczaj błędne, ponieważ wcześniejsze skrypty zostały już uruchomione, a ich ponowne uruchomienie w przypadku częściowo zmienionego schematu zmienia jeden problem w trzy. Napisz migrację korekcyjną z miejsca, w którym schemat się znajduje, do miejsca, w którym powinien się znajdować.

Następnie określ, dlaczego migracja nie była idempotentna. To jest prawdziwy problem.

Krótka lista kontrolna przed wysłaniem aktualizacji modułu

Lista, którą prowadzę:

1. Wersja klasy głównej, najwyższa uaktualnij-*.php plik: czy one pasują?
2. Czy każda funkcja aktualizacji ma nazwę odpowiadającą wersji pliku, do którego jest przypisana?
3. Czy przy każdej zmianie schematu sprawdzasz najpierw, czy została już zastosowana?
4. Czy każda konfiguracja zapisuje pętlę po wszystkich sklepach?
5. Czy każdemu nowemu kluczowi konfiguracyjnemu przypisywany jest domyślny klucz dla istniejących instalacji?
6. Czy porównywałeś już kopię rzeczywistego sklepu?
7. Zainstalowano starą wersję, dodano dane, a następnie zaktualizowano?
8. Ta sama ścieżka w przypadku multistore?
9. Coś przydatnego logowane przed każdym zwróć fałsz?
10. zaraźliwy Błąd jak również Wyjątek?
11. Stare pliki aktualizacji są nadal dostępne dla sprzedawców, którzy mają kilka wersji opóźnienia?
12. Rejestr zmian nakazujący sprzedawcom tworzenie kopii zapasowych?
13. Na dużym stole, jak długo to jest? ZMIANA trzymasz zamek?

Punkty 6 i 7 są tymi, które ludzie pomijają i na nich wyłapują najwięcej.

Wniosek

Aktualizacja modułu PrestaShop Problemy są kłopotliwe z jednego powodu: nic ich nie zapowiada. Moduł bez problemu zgłasza nową wersję. Strona administracyjna ładuje się. Żadnych logów, chyba że sam je stworzyłeś. Tymczasem Twój kod oczekuje jednej rzeczy, baza danych przechowuje inną, która pozostaje nietknięta, dopóki ktoś nie użyje tej jednej funkcji, która znajduje się pomiędzy.

Traktuj schemat jako część wydania. Twórz migracje, które przetrwają drugie uruchomienie. Rejestruj zdarzenia. Przeprowadź migrację przez etap przygotowawczy, zanim zrobi to jakikolwiek sprzedawca. Po stronie frameworka, PrestaShop dokumentacja rozwoju modułu jest miejscem, od którego należy zacząć.

Jeśli masz pytania lub potrzebujesz pomocy w zakresie wydajności lub migracji witryny, nasi eksperci są do Twojej dyspozycji. Skontaktuj się z zespołem Knowband pod adresem [email chroniony] już dziś skorzystaj z niezawodnych wtyczek e-commerce dostosowanych do Twoich potrzeb w zakresie e-commerce.