Devpost#14 Implementacja PDO oraz transakcji do bazy danych.

Wczoraj, udało mi się zakończyć prace nad modułem do mojego projektu, który pozwala dodawać nowe mieszkania do systemu. Był to pierwszy dość spory element, który należało zaimplementować w pierwszej kolejności.

Sanityzacja i walidacja formularza

Na początku, wziąłem się za napisanie klas sanityzujących pobrane dane, tak aby pozbyć się wszelkich brudów, które potencjalnie mogą trafić z formularza. Następną rzeczą było sprawdzenie, czy wszystkie wymagane pola zostały uzupełnione i czy zostało to zrobione poprawnie.

W tym miejscu, na początku miałem drobną zagwozdkę, ponieważ jest kilka poprawnych możliwości uzupełnienia formularza. Dlatego też, musiałem zaprojektować mechanizm, który będzie dostosowywał się do ilości oraz rodzaju otrzymanych danych. 

Na końcu, napisałem prostą klasę, która jest odpowiedzialna za obsługę przypadku, gdyby jakiś user postanowił zepsuć system walidacji i usunąłby któryś z inputów. Cały mechanizm informowania o błędach, wyświetlany jest u usera za pomocą Twiga, który otrzymuje tablicę z ewentualnymi błędami i na jej podstawie wyświetla odpowiednie rzeczy w widoku.

Implementacja PDO i transakcje

Jedną z rzeczy, którą musiałem dobrze przemyśleć było wstawianie mieszkań do bazy danych. W procesie dodawania mieszkania, biorą udział dwie, a maksymalnie cztery tabele. To sprawiło, że do bazy muszą zostać wykonane cztery różne zapytania w zależności od konfiguracji dodawanego mieszkania. 

Do tej pory, do komunikowania się z bazą danych, używałem mysqli. Jednak za radą znajomego, postanowiłem zaimplementować do tego celu PDO, z którego notabene wcześniej nie korzystałem. Same zmiany w metodach, które wcześniej używały mysqli nie były aż tak znaczące. Z istotniejszych rzeczy, odrobinę różni się konstruktor PDO od tego, który łączył się z bazą za pomocą mysqli.

No koniec została rzecz, która mocno mnie zastanawiała. Jak obsłużyć zapytania, które muszą zostać wykonane równocześnie, gdzie dodany rekord do tablicy jest relacyjny z inną tabelą, który pojawi się dopiero za chwilę. Rozwiązaniem na ten cały problem stanowiły transakcje

Niesamowicie mądra rzecz, której wcześniej nie znałem. W dużym skrócie dla tych, którzy wcześniej nie spotkali się z tym terminem. Transakcje pozwalają bezpiecznie wykonywać zapytania do kilku tabeli w bazie. Zazwyczaj wykonujemy ją w try catchu, gdzie w try’u rozpoczynamy transakcję. Następnie umieszczamy zapytania do różnych tabel. Bardzo pomocna jest metoda PDO::lastInsertId, która pozwala przechwycić ostatnio wprowadzone do bazy ID. Bardzo ułatwia to obsługę relacji w dalszym ciągu tego procesu. Transakcje kończymy commitem. Jednak co w tych transakcjach jest takiego super? Ano, jeśli dodajemy dwa rekordy, do dwóch różnych tabel i są one ze sobą w relacji, to chroni nas przed sytuacją, gdzie jeden rekord się doda, a drugi nie. Załóżmy, że coś przerwało połączenie z bazą po dodaniu pierwszego rekordu. W tym momencie, dostajemy tak zwany rollBack. Transakcja, gdy się wykonuje to musi wykonać się od początku do końca. Jeśli coś ją przerwie w połowie, to to, co już zostało wykonane zostanie cofnięte do stanu przed rozpoczęciem transakcji. Dzięki czemu uniknęliśmy problemów z brakiem niezbędnych danych w bazie. 

Co teraz?

Wydaje mi się, że warto byłoby stworzyć kiedyś osobny wpis poświęcony Transakcjom, może akurat komuś by się przydał. Jednak zanim to, to sam muszę się dobrze tego nauczyć.

Najbliższe dni planuję poświęcić na wdrażanie opcji “Lista mieszkań”. Będzie jedna większa zagwozdka, nad którą już właściwie siedzę, bo trzeba to dobrze zaprojektować zanim zacznę kodzić. Plan też jest taki, aby w ramach edukacji samemu napisać, całą “szukajkę” oraz paginację. Choć, mógłby skorzystać z gotowca, którego dostarcza template, z którego korzystam. Wyjdzie w praniu, czy uda mi się to napisać, czy jednak skorzystam z gotowca 🙂

Leave a Reply

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *