Ruckusing Migrations część 4 – praktyk ciąg dalszy

Zbliżamy się powoli do końca serii postów poświęconych bibliotece Ruckusing Migration.

W przedostatnim wpisie poruszę temat transakcji i logowania zdarzeń a także opiszę jak można zrzucić schemat bazy danych do pliku. Zachęcam także do przeczytania pierwszego, drugiego i trzeciego postu poświęconego Ruckusing Migration.

Transakcje

Transakcje w Ruckusing Migration obsługuje się bardzo prosto i wystarczy do tego znajomość trzech metod. Chodzi o start_transaction(), commit_transaction(), rollback_transaction(). Całość zobrazuje kod poniżej:

Kod jest raczej łatwy do zrozumienia, ale gwoli ścisłości wszystko wyjaśnię. W pierwszej kolejności należy pobrać adapter, ponieważ to z jego poziomu dostępne są metody służące do obsługi transakcji. W sekcji try rozpoczynamy transakcje metodą start_transaction() wykonujemy zapytania kod SQL i zatwierdzamy transakcję metodą commit_transaction(). Jeśli jednak coś pójdzie nie tak to w sekcji catch wycofujemy transakcję i wyświetlamy wiadomość z wyjątku. I tyle.

Logowanie zdarzeń do pliku

W zasadzie nie ma potrzeby wykonywać żadnych specjalnych działań aby logować zdarzenia do pliku. Ta opcja jest włączona domyślnie a my możemy ustalić w pliku konfiguracyjnym gdzie plik logu ma być przechowywany (chodzi o klucz log_dir na końcu pliku konfiguracyjnego). Nazwa pliku z logami odpowiada nazwie klucza w tablicy z danymi konfiguracyjnymi biblioteki.

A co jeśli będziemy chcieli dodać własne logi? W tym celu musimy użyć klasy Ruckusing_Util_Logger , jej instancję możemy pobrać za pomocą metody get_logger() dostępnej z poziomu adaptera. Istnieje także metoda set_logger() za pomocą, której można ustawić obiekt klasy, która ma posłużyć do logowania zdarzeń.

Gdy już mamy pobraną instancję loggera możemy użyć metody log i w jedynym parametrze jaki przyjmuje podać treść logu. Przykładowo dla poniższego kodu:

W pliku logu zostanie zapisana następująca linia:

Zrzut bazy danych

Zrzut bazy danych możemy wykonać z poziomu CLI za pomocą polecenia:

W ten sposób do katalogu db znajdującego się w głównym katalogu biblioteki zostanie zapisany plik scheme.txt, który będzie zawierał schemat bazy danych w postaci kodu SQL.

Podobnie jak w przypadku logów istnieje możliwość skonfigurowania ścieżki, do której będzie zapisywany plik schematu. Odpowiada za to klucz db_dir, który znajduje się na samym końcu pliku konfiguracyjnego.

I to by było na tyle…

…w następnym odcinku (który będzie jednocześnie ostanim) opiszę w jaki sposób tworzyć własne zadanie, które można uruchomić z poziomu CLI. Do przeczytania już wkrótce!

Posty które mogą Cię zainteresować:

2 Responses to Ruckusing Migrations część 4 – praktyk ciąg dalszy
  1. CiekawyWojtek Odpowiedz

    Dobre stare PDO ma to samo, do logów można napisać własnego traita, jedynie zrzut bazy danych można wykorzystać. To nie lepiej już dołączyć Propela lub Doctrine do projektu?

    • Michał Janicki Odpowiedz

      W sensie PDO ma podobną obsługę transakcji? Odnośnie logów się zgadzam a odnośnie Propela i Doctrine niekoniecznie. Istnieją projekty, w których nie ma sensu dodawać ORMa.

Dodaj komentarz

Your email address will not be published. Please enter your name, email and a comment.