Jest kilka niezwykle popularnych metod – metoda prostokątów (dzielimy całkowany przedział na n mniejszych podprzedziałów i przybliżamy ich pole prostokątem), metoda trapezów (jak w metodzie poprzedniej tylko tym razem przybliżamy pole trapezem), metoda parabol (to już chyba jasne?). Mają one kilka wspólnych cech: są deterministyczne, teoretycznie możemy przy ich pomocy uzyskać wartość całki z dowolną dokładnością (ogranicza nas „tylko” czas i szybkość procesora). Gdy czas jest dla nas kluczowy (i nie mamy go za dużo) a nasza funkcja jest wielowymiarowa, możemy spróbować szczęścia używając niedeterministycznej metody całkowania numerycznego – metody Monte Carlo.

Aby ją zobrazować posłużę się przykładem zaczerpniętym z Wikipedii. Załóżmy, że chcemy wyznaczyć przybliżoną wartość liczby pi. Możemy wymyślić sobie następujący eksperyment: weźmy kwadrat o boku o znanej długości i wpiszmy w niego koło.

Teraz możemy losować punkty w środku kwadratu i zliczać te, które „trafiły” w koło. Sprawdzamy to licząc odległość punktu od środka kwadratu i sprawdzając, czy jest ona mniejsza (bądź równa) promieniowi naszego koła. Oznaczmy liczbę wylosowanych punktów jako n i liczbę punktów znajdujących się w kole jako t. Możemy policzyć przybliżony stosunek pola koła do pola kwadratu: k = t / n. Wiedząc, że k = pi * r² / 4r² wyznaczamy pi. Możemy zwiększać dokładność naszego szacowania zwiększając liczbę losowanych punktów.

Mamy już właściwie wszystkie niezbędne informacje aby liczyć wartości całek oznaczonych metodą Monte Carlo. Załóżmy, że chcemy policzyć całkę oznaczoną na przedziale <a, b> z funkcji f(x). Na początku losujemy n wartości z przedziału całkowania (x₁, x₂, …, x_i, …, x_n) i liczymy średnią s z wartości f(x_i). Wartość całki wynosi c = s * (b – a).

Skąd bierze się powyższy wzór? Intuicja jest następująca: licząc naszą średnią s wyznaczamy średnią „wysokość” funkcji. Znając ją liczymy pole prostokąta o bokach (b – a) oraz s.

Implementacja metody nie jest trudna. Przygotowałem przykładową implementację w języku C. Zachęcam do zapoznania się z kodem. Porównuje on metody prostokątów, trapezów oraz Monte Carlo. Jak można zauważyć, w przypadku jednowymiarowym metody deterministyczne są szybsze i dokładniejsze.

Niniejszy wpis jest tylko krótkim wstępem do metody Monte Carlo, która jest wykorzystywana do granic możliwości przez fizyków (przykładem jest Wrocławska Grupa Neutrinowa, która używając tej metody symuluje oddziaływanie neutrin z materią). W następnym wpisie pokażę przykładowe zastosowanie tej metody do konkretnego problemu fizycznego.

Dzisiaj zajmiemy się warstwą Modelu – niewątpliwie najbardziej skomplikowaną częścią tego modelu. Efektywne zaimplementowanie tej warstwy to tak naprawdę najważniejsza część – reszta jest dość prosta do napisania i tam raczej cudów nie ma. Stworzymy klasę abstrakcyjną, która pozwoli na rozszerzanie modeli w nieskończoność, korzystając z tego samego interfejsu. W następnej części zaimplementujemy także klasę potomną od naszego abstrakcyjnego modelu, która będzie pobierała dane z baz danych. Wykorzystamy w tym celu PDO, co będzie doskonałym ćwiczeniem w programowaniu z użyciem tego zestawu klas.

Nasz Model, z racji tego, że ma być prosty, nie będzie uwzględniał takich rzeczy jak połączenia między danymi, czy też szukanie po warunkach – przyjemność implementacji tych funkcji pozostawiam czytelnikowi. W razie problemów chętnie posłużę radą.

Własności naszych danych:

Aby efektywnie i prosto zaimplementować nasz Model, dane będą spełniały pewne właśności, które są dość powszechne i nie będą specjalnie zaskakujące. Prawdę mówiąc, wszystkie te własności spełnia każda dobrze stworzona baza danych. Przede wszystkim, każdy zestaw danych będzie jednoznacznie reprezentowany przez identyfikator liczbowy (ID). Jest to ważne, ponieważ musimy mieć jakąś szansę na dostanie się do naszych danych i musi to być szansa niezależna od ich typu. ID jest najprostszym sposobem. Drugą własnością będzie to, że struktura danych będzie znana przed jakąkolwiek manipulacją nimi. Jest to dość oczywiste, gdyż musimy wiedzieć tak naprawdę co pobieramy. Teoretycznie możliwe jest także odrzucenie tej własności – w przypadku pobierania np. z pliku tekstowego w formacie:

id = 2
foo = 'bar'
p = 12
x = 19.282

Własność nie musi być spełniona, gdyż mamy podane etykiety danych. My jednak założymy, że strukturę danych znamy – ułatwi nam to w przyszłości np. używanie naszego modelu z bazą danych.

Co chcemy zrobić z danymi?:

Pytanie wydaje się trywialne, ale warto się nad nim zastanowić. To, co nasuwa się samo to oczywiście możliwość pobierania danych z naszego źródła. Po to w końcu tworzymy nasz model, prawda? Ale nie tylko. Przydałaby się także możliwość manipulacji danymi już pobranymi, a także zapis zmanipulowanych danych spowrotem do źródła danych, tworzenie nowych danych oraz usuwanie danych ze źródła. To wszystko będzie realizowane właśnie przez nas model. Warto mieć tą wiedzę jeszcze przed pisaniem czegokolwiek, pozwoli to nam na głębsze przemyślenie struktury kodu. Ogólnie, przed napisaniem czegokolwiek polecam najpierw rozplanować sobie program na kartce – piszemy wtedy kod zdecydowanie lepszy, bardziej przemyślany i przez to krótszy.

Abstrakcyjny model klasy:

Skoro już wiemy, czego pragniemy od naszej klasy, możemy zacząć ją powoli tworzyć. Wiemy, że każdy rekord jest reprezentowany przez ID. Skoro chcemy ładować dane, stwórzmy metodę load, przyjmując nasz ID jako argument. I tak, kod:

$model->load(1);

Załaduje nam rekord o ID równym 1 ze źródła danych. Nasze dane będziemy przechowywać w tablicy $data. Pozwoli nam to na prostą implementację manipulowania danymi (wprost) oraz pobierania ich. Aby korzystać z wygodnej składni w stylu:

echo $model->foo;
$model->foo = 'bar';

Skorzystamy z magicznych metod PHP: funkcji __get($key) oraz __set($key,$data). Korzystając z tego, że mamy dane w tablicy, implementacja tych metod jest trywialna:

public function __get($key) {
	if( !isSet($this->data[$key]) ) return NULL;
	return $this->data[$key];
}
 
public function __set($key,$value) {
	$this->data[$key] = $value;
}

Oczywiście, nie uwzględniamy tutaj np. walidacji danych. Musimy to uwzględnić sami, nim jeszcze przypiszemy dane do modelu. Oczywiście, są też inne metody rozwiązania tego problemu, nie opiszę ich jednak w tym artykule z dwóch powodów – po pierwsze, model musi pozostać prosty, a po drugie, nie chce mi się.

Oczywiście, musimy mieć także strukturę daną w momencie tworzenia obiektu. Stwórzmy więc statyczną tablicę $structure, przechowującą naszą strukturę danych oraz structure(), metodę uruchamianą w konstruktorze, która będzie zwracała naszą strukturę danych do tablicy. Aby zapewnić także możliwość wstawiania nowych rekordów do źródła danych, stwórzmy także wartość logiczną $virtual. Dane będą wirtualne, gdy nie będą istniały w źródle danych – pojawią się tam dopiero, gdy je zapiszemy. Praktyczna implementacja takiego konstruktora może wyglądać następująco:

public function __construct( $id = NULL ) {
	istatic::$structure = static::structure();
	$this->virtual = is_null($id)? TRUE : FALSE;
	if( !$this->virtual ) $this->load($id);
}

Jak widać, w momencie gdy tworzymy model, ładujemy statyczną metodę structure(), która zwraca nam tą strukturę. To bardzo praktyczne – w dzieciach tej klasy wystarczy jedynie nadpisać tą metodę.

Podsumowanie:

Reszta metod jest metodami abstakcyjnymi i nie będziemy się nimi zajmować. Poniżej zamieszczam gotową klasę, która będzie stanowić interfejs naszych modeli. Jak widać, nie jest to takie trudne. Jakiekolwiek funkcje, które są zależne od typu danych powinny być nadpisywane przez klasy potomne.

Przykładowa klasa AbstractModel.php:

<?php
abstract class AbstractModel {
	protected static $structure;
	protected $data, $virtual;
 
	public function __get($key) {
		if( !isSet($this->data[$key]) ) return NULL;
		return $this->data[$key];
	}
 
	public function __set($key,$value) {
		$this->data[$key] = $value;
	}
 
	public function __construct( $id = NULL ) {
		if( !isSet(static::$structure) ) static::$structure = static::structure();
		$this->virtual = is_null($id)? TRUE : FALSE;
		if( !$this->virtual ) $this->load($id);
	}
 
	abstract public function save( $id = NULL );
	abstract public function delete();
	abstract public function load( $id );
	abstract static public function structure();
}
?>

To wszystko na dziś. Mam nadzieję, że poradnik będzie przydatny!

Na przestrzeni wieków (brzmi dumnie) programiści sieciowi różnie radzili sobie z tym problemem. Czy to za pomocą wyrażeń regularnych, czy za pomocą wbudowanych w język funkcji niekoniecznie do tego służących. Od PHP 5.2 istnieją jednak dedykowane rozwiązania do radzenia sobie z tym problemem i o nich opowiemy w tym artykule.

Dlaczego to jest fajne?

Rodzina funkcji filter_* jest bardzo ciekawym narzędziem i jest ciekawa z kilku powodów. Przede wszystkim, posiada dość bogatą ofertę filtrów, które możemy zastosować. Działa także dwojako – pozwala na weryfikację danych jak również ich przetworzenie (sanitizing) do obowiązującego formatu. Wprowadza to pewną kulturę kodu – zamiast używać konstrukcji w stylu:

1

$foo = strip_tags($foo);

Używamy wywołania funkcji, która automagicznie zamienia nam to co w zmiennej na przetworzony odpowiednik.

No ok, ale o czym mowa?

Sprawa jest dość prosta i spowadza się do kilku prostych funkcji, których używamy w naszej aplikacji. Są to, kolejno: filter_input, filter_val, filter_var_array i filter_input_array. Są to tak naprawdę dwie funkcje wraz z ich „tablicowymi” odpowiednikami, gdybyśmy chcieli filtrować kilka zmiennych na raz.

filter_input:

filter_input służy do filtrowania danych, które zawarte są w supertablicach, które pobierają dane od użytkownika i maszyny – $_POST, $_GET, $_SERVER, $_COOKIE i $_ENV. Składnia jest następująca:

1

filter_input( $typDanych, $klucz, $używaneFiltry, $opcje );

$typDanych wskazuje tablice, której klucz wpisujemy – jest to jedna ze stałych: FILTER_POST, FILTER_GET, FILTER_SERVER, FILTER_COOKIE lub FILTER_ENV. Myślę, że nazwy tłumaczą wszystko i nie trzeba się nad nimi specjalnie rozwodzić. $klucz wskazuje na daną, którą chcemy przefiltrować – przykładowo, gdy chcemy filtrować $_POST['foo'], $typDanych ustawiamy na FILTER_POST, a $klucz na ‘foo’. $używaneFiltry to zmienna stanowiąca tak naprawdę wszystko. Tutaj ustawiamy, jakie filtry mają zostać użyte, ‘scalając je’ operatorem binarnej alternatywy (co pewnie zna każdy programujący w C) „|”. Ostatni argument $opcje jest używany, gdy ustawiamy flagę, która z takich opcji korzysta. Jest to tablica asocjacyjna Myślę, że najlepiej zobrazuje to przykład (a nawet kilka):

1
2
3
4
5

$options = array( 'flags' => FILTER_FLAG_ALLOW_HEX, 'min_range' => 100, 'max_range' => 200 );
if( filter_val( FILTER_POST, 'foo', FILTER_VALIDATE_INT, $options ) !== FALSE ) {
// jeżeli $_POST['foo'] jest liczbą całkowitą w systemie dziesiętnym lub heksadecymalnym od 100 do 200 to wykonaj ifa.
}
filter_val( FILTER_POST, 'foo2', FILTER_SANITIZE_INT, $options ); // podstawia NULL, jeżeli dana nie spełnia założeń...

Jak widać, użycie tych filtrów jest bardzo proste. Przede wszystkim jest także rozszerzalne – niektóre biblioteki dodają nowe filtry, których listę możemy sprawdzić za pomocą funkcji filter_list.

Lista wszystkich filtrów

Na oficjalnej stronie PHP jest poradnik dotyczący wszystkich funkcji z rodziny filter_. Możemy znaleźć go pod tym adresem.

Podsumowanie

Rodzina tych funkcji stanowi kompleksowe rozwiązanie problemu filtrowania danych wysyłanych przez użytkownika do naszej aplikacji dla programistów PHP. Piszę o nich, gdyż rzadko kiedy widzę zastosowanie ich w praktyce – a szkoda, bo są to dopracowane i bardzo przydatne przy budowaniu stron funkcje.

Zatem, do napisania!

Tryb interaktywny

Jest wiele sposobów na przekazanie lftp serwera z którym pragniemy się połączyć, jednak dla mnie najwygodniejszy okazał się jeden z nich:

$ lftp [protocol]://[username]@[server]
$ lftp sftp://user@myserver.com # tak, żeby podać konkretny przykład

Po zatwierdzeniu jesteśmy pytani o hasło, po czym naszym oczom ukazuje się konsola interaktywna. Kilka cech, które szczególnie przypadły mi do gustu:

• uzupełnianie nazw plików,
• nie wyświetla zbędnych wiadomości od serwera (chyba, że sobie tego zażyczymy),
• zarządzanie zadaniami wykonującymi się w tle (analogicznie jak w shellu),
• możliwość przekierowania wyjścia komendy do pliku bądź innej komendy,
• możliwość wykonywania zewnętrznych programów (komenda !).

Nie zagłębiałem się bardziej (ponieważ głównie zająłem się możliwością wykonywania skryptów, o czym niżej), ale w dokumentacji można się dowiedzieć, że możemy np. stosować zakładki, czy zrobić aliasy do najczęściej używanych komend.

Mi przydały się trzy komendy:

• help – tego chyba nie muszę tłumaczyć :),
• cd folder – przejście do zdalnego folderu,
• put plik_lokalny – przesyła na serwer dany plik.

Mimo iż nie planowałem używać lftp w trybie interaktywnym, okazał się on na tyle wygodnym programem, że teraz on będzie moim głównym klientem FTP i podobnych. Jako osobnik nie lubiący opuszczać konsoli (chociażby po to, żeby skorzystać z GFTP…) ten program bardzo mi się przyda.

Skrypty

Wracając do mojej automatyzacji – okazuje się, że nie muszę wiedzieć praktycznie nic więcej, żebym był w stanie wykonać swoje zadanie. Skrypty lftp są zwykłymi plikami tekstowymi z ciągiem komend jakie wydajemy w trackie sesji interaktywnej z komendą otwierającą połączenie na samym początku. Przykładowy skrypt mógłby wyglądać tak:

open sftp://user@server.pl/
cd dir1
put one.html
put two.html
cd dir2
put img.png

Mając nazwy plików, które muszę wysłać na serwer, bez problemu generuję sobie skrypt analogiczny do powyższego. Potem korzystając z komendy:

$ lftp -f skrypt

wszystkie pliki są wysyłane na serwer (po uprzednim wpisaniu hasła).

Słowa końcowe

Program lftp zaoszczędził mi wiele nerwów – po części dlatego, że nie lubię wychylać nosa zza konsoli a po części dlatego, że lubię automatyzować nużące czynności. Do obu celów nadaje się idealnie – mam nadzieję, że i wam się przyda.

Do następnego,
sznurek.

Mimo tego, że napisanie aplikacji w oparciu o ten model wydaje się skomplikowane, wcale takie nie jest. Wystarczy wiedza z zakresu obiektowo-orientowanego programowania w dowolnym języku (my wybierzemy PHP) i trochę cierpliwości. W tym artykule postaram się odpowiedzieć na pytanie, jak stworzyć pierwszą część takiego wzorca – Model danych. Opowiem też o tym, za co odpowiada która część i dlaczego kod, który napiszemy nie działa na 90% polskich hostingów. Zatem do dzieła!

Model… View… Controller? O co w tym wszystkim chodzi?

Być może dziwne nazwy, które zawarte są w nazwie tego wzorca mogą odstraszać, ale nie jest to wcale trudna rzecz.  Przedstawię tutaj pomocniczy schemat, który na przykładzie bloga przybliży Wam, w czym rzecz.

Myślę, że powyższy schemat dość dobrze pokazuje, o co w tym wszystkim chodzi. Zapytanie przekazywane jest do kontrolera, kontroler przetwarza je,  pobierając z modeli te dane, które są mu potrzebne (być może nie tylko dane wpisu – może też dane autora, komentarzy itp.) i przekazuje wykonywanie dalej, do widoku (view).

Dla tych, do których przemawia jedynie kod, przedstawiam mały, poglądowy kod jak mogłoby to wyglądać (pomijam tutaj model):

Kontroler:

<?php
class PostController extends ControllerHandler {
	// ...
	public function view( $id ) {
		$post = new Post($id);
		if( !$post ) { // wpis o tym ID nie istnieje.
			$this->error('404');
			return;
		}
 
		$this->viewVars['post-content'] = $post->content; // Potrzebujemy tresc wpisu
		$this->render(); // Przekazujemy wykonanie do widoku.
	}
	// ...
}
?>

Widok:

<h1>Wpis na blogu:</h1>
<?php echo $v['post-content']; ?>

Jak widzimy, pobieranie danych i ich walidacja (przykładem jest tutaj wywalenie błędu, gdy nie ma wpisu o ID 12 jest realizowane w kontrolerze, zaś widok zajmuje się tylko wyświetleniem danych na ekran.

Szczegóły implementacyjne

Wiemy już, jak to powinno działać. Pozostaje pytanie – jak to zaimplementować? W następnych częściach naszego artykułu przejdziemy do konkretów, implementując każdy szczegół z osobna.

Do napisania!

• automatyczną ochronę przed atakami typu SQL Injection,
• możliwość korzystania z każdego silnika bazodanowego transparentnie, przy użyciu tego samego API – to kwestia zmiany jednej linijki w konstruktorze!
• mechanizmy transakcji (o ile obsługuje je nasza baza danych – MySQL, PostgreSQL i SQLite3 – obsługują) – możliwość cofnięcia dowolnych zmian w bazie danych do momentu przed manipulacją za pomocą jednej funkcji! Naprawianie błędów w bazie pozostawionych przez nieudane zapytania jeszcze nigdy nie była tak prosta!
• przygotowane zapytania (ang. prepared statements) – zoptymalizowany sposób na wysyłanie dowolnej ilości identycznie skonstruowanych zapytań z różnymi argumentami,
• pełny dostęp do informacji o aktualnym stanie bazy danych (błędy itd.) w każdej chwili,
• możliwość denerwowania głównego webmajstra Natodii,
• rozbudowany system wyjątków,
• możliwość pozwolenia dziadkowi PHP4 spokojnie umrzeć;

Pozwolę sobie skoncentrować się na kawałkach kodu wraz z objaśnieniem ‘o co chodzi’ – opis całości biblioteki znajduje się tutaj.

1. Instalacja:

W przypadku Debiana, którego używam instalacja odbywa się poprzez zainstalowanie odpowiednych paczek do bazy danych:

# aptitude install php-mysql php-sqlite php-pgsql # i tak dalej

Dla Windows polecam użycie WampServera – ma on już wszystko, czego potrzeba do korzystania z PDO. Wymaga to jednak aktywacji. Aby aktywować PDO, należy kliknąć na ikonkę serwera w trayu i w menu PHP -> PHP Extensions zaznaczyć potrzebne nam składniki i bazy danych (np. php_pdo.dll, php_pdo_mysql.dll) po czym zrestartować serwer.

2. Nawiązywanie połączenia z bazą danych:

Wszystko gotowe? Środowisko skonfigurowane? Czas więc zrobić pierwszy krok w manipulacji bazą danych – połączyć się z nią! Przykład będzie dla bazy MySQL:

try {
 $db = new PDO( 'mysql:host=localhost;dbname=nazwabazy', $user, $password );
}
catch( PDOException $e ) {
 // ewentualna obsługa wyjątku...
}

Jak wszyscy widzą, na argumenty konstruktora składają się (w tym wypadku):  łańcuch znaków deklarujący typ bazy z którą się łączymy i parametry, użytkownika i hasło. Uwaga! W przypadku baz takich jak np. SQLite3, gdzie logowania nie ma, po prostu pomijamy te parametry dot. użytkownika i hasła – są one opcjonalne. Sercem tego systemu jest właśnie ten string formatujący – za jego pomocą definiujemy bazę, z jaką mamy się połączyć. Reszta API jest identyczna – czy to MySQL, czy SQLite, czy PostgreSQL, czy MSSQL, czy cokolwiek sobie wymyślisz, a ma sterownik w PDO.

Jako czwarty argument konstruktor przyjmuje tzw. atrybuty Są to flagi, których postawienie pozwala uruchomić zaawansowane (i niekoniecznie działające wszędzie) funkcjonalności samej bazy danych, lub PDO. Wszystkie (oprócz PDO::ATTR_PERSISTENT, która jest chyba najprzydatniejszą) można potem ustawić za pomocą funkcji setAttribute.

$db = new PDO( 'sqlite:file=file.sqlite', NULL, NULL, PDO::ATTR_PERSISTENT | PDO::ATTR_FETCH_TABLE_NAMES );
$db->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT ); // PDO nie sypie wyjątkami - wyświetla jedynie warningi
// po więcej atrybutów odsyłam na: http://pl.php.net/manual/en/pdo.constants.php i strony konkretnych driverów w dokumentacji

Jako, że PDO ma swoje destruktory, aby zerwać połączenie wystarczy usunąć referencję za pomocą funkcji unset:

unset( $db ); // zrywa połączenie z bazą danych

3. Wykonywanie zapytań:

Przechodzimy do najważniejszej części – wykonywania zapytań do naszej (połączonej już) bazy danych. Są dwa sposoby, dlatego rozdzielę ten podpunkt.

3a. Surowe zapytania używając $db->query( … ):

Jest to zdecydowanie najgorszy sposób z racji tego, że nie ma wbudowanej ochrony przeciwko SQL Injection. Niemniej jednak, czasem takie „surowe” zapytania są przydatne. Pamiętaj tylko, aby pod ŻADNYM pozorem nie korzystać z tego sposobu w połączeniu z surowymi danymi z formularzy od użytkowników – powinny one zostać wcześniej przetworzone (może w tym pomóc rodzina funkcji ctype_, *val oraz PDO::quote)!!!

try {
 $sql = $db->query( 'SELECT * FROM foo WHERE bar = 2' );
 while( $row = $sql->fetch( PDO::FETCH_ASSOC ) ) { // PDO::FETCH_ASSOC sprawia, że kolejne wiersze tabeli są wrzucane do tablicy asocjacyjnej z nazwami kolumn.
   // Domyślnie wrzucane są do tablicy numerowanej od 0 do x gdzie x-1 to liczba kolumn (w kolejnosci) + dorzucane sa odwolania jako nazwy kolumn. Aby zostawic same numerki - skorzystaj z PDO::FETCH_NUM
   echo $row[ 'id' ];
 }
}
catch( PDOException $e ) {
 // ...
}

3b. Zapytania przygotowane:

Zdecydowanie lepszy sposób. Dlaczego? Chroni nas przed SQL Injection, pozwala się nam nie powtarzać i rozdziela budowanie zapytania na fazę budowy i wykonywania.

$sql_one = $db->prepare( 'SELECT * FROM foo WHERE bar = ? AND x = ?' ); // to *nie* wykonuje jeszcze tego zapytania
$sql_one->execute( Array( 12, 13 ) ); // wykonuje zapytanie, pod ? wstawiając kolejno: 12, 13
$sql_two = $db->prepare( 'SELECT * FROM foo WHERE :col = :val AND :coltwo = :valtwo' );
$sql_two->bindColumn( ':col', 'bar' ); // podstawia pod :col kolumnę bar
$sql_two->bindColumn( ':coltwo', 'x' ); // podstawia pod :coltwo kolumnę x
$sql_two->bindParam( ':val', 12, PDO::PARAM_INT ); // podstawia pod :val wartość 12. PDO::PARAM_INT jest <strong>opcjonalne</strong>
$sql_two->execute( Array( ':valtwo' => 13 ) ); // wykonuje to samo polecenie co $sql_one
$res = $sql_one->fetchAll( PDO::FETCH_ASSOC ); // jeden ze sposobów pobierania wyników - wszystkie na raz są wrzucane do tablicy
// można też skorzystać ze 'starego' sposobu:
while( $row = $sql_two->fetch( PDO::FETCH_ASSOC ) ) {
  // ...
}
$sql_one->execute( Array( ':val' => 14, ':valtwo' => 18 ) ); // wyślijmy jeszcze jedno takie samo zapytanie, z innymi argumentami

Jak zauważyliśmy, możemy tutaj dowolnie manipulować wartościami i kolumnami wrzucanymi do zapytania jeszcze PRZED wysłaniem ich do bazy danych – to wielka wygoda. Ponadto możemy jedno przygotowane zapytanie wykonać n razy, zmieniając jedynie parametry.  I wszystkie wprowadzane dane są zabezpieczone przed SQL Injection, więc można tam wstawiać nawet surowe dane podane z formularzy. Czyż nie jest to raj programisty? :)

Mam nadzieję, że przekonałem Was do tego sposobu. Może jest odrobinę bardziej rozwlekły od pierwszego, ale nauczenie się korzystania z niego pozwoli Wam na pisanie bardzo dobrego i bezpiecznego kodu do interakcji z bazą danych. A o to chyba tutaj chodzi, prawda?

I, jeszcze aby do końca osłodzić Wam życie…

4. Transakcje:

Wyobraźmy sobie następującą sytuację. Mamy sobie ogromniastą bazę danych w formacie-koszmarze, przygotowaną przez programistę-troglodytę – powiedzmy, że w XMLu (sry, Javowcy, musiałem :(). Jako wspaniali, mądrzy i światli programiści korzystający z dobrodziejstw XXI wieku postanawiacie wrzucić to całe cholerstwo do jakiejś cywilizowanej bazy danych typu MySQL czy Postgre. Wyposażeni w nowo nabytą wiedzę dot. PDO postanawiacie skorzystać z tej wspaniałej technologii. Przygotowujecie zapytanie, przekazujecie argumenty – wszystko jest fajnie. Lecz nagle, BANG! Skrypt podawał złe dane! Dwa wątki się skrzyżowały i nastąpiła sytuacja wyścigu! Zrozpaczony tym, że aktualnie w Twojej bazie danych masz połowę niekoniecznie poparawnych rekordów spędzasz sporo czasu na znalezienie uszkodzonych, usunięcie bezsensownych itd. Wybacz, time limit exceeded, Ziemia została zjedzona przez Obcych. Zawiodłeś, stary.

Ale programiści baz danych przewidzieli coś specjalnie na takie okazje – mechanizm transakcji! Na czym to polega? Za pomocą metody przekazujesz do bazy danych, że zaczynasz transakcje – w tym momencie baza danych ustanawia punkt, do którego wróci, gdy coś pójdzie nie tak. Potem wykonujesz polecenia – nie są one jednak wykonywane w bazie danych. Dopiero, gdy zwolnisz transakcje za pomocą drugiej metody, wtedy zacznie się manipulacja danych. Co to daje?

• Masz pewność, że zostaną wykonane wszystkie zapytania, jakie znajdowały się w obrębie transakcji – w przeciwnym wypadku zostanie zgłoszony wyjątek,
• W przypadku błędu lub z innego powodu będziesz w stanie za pomocą jednej metody powrócić do stanu bazy sprzed transakcji,
• Baza danych optymalizuje zapytania na bieżąco – przez co wszystko jest szybsze.

Co najlepsze, wykorzystanie dobrodziejstw transakcji jest w PDO bardzo proste. Zilustruje to poniższy przykład:

try {
 $db->beginTransaction(); // rozpoczynamy transakcje
 $sql = $db->prepare( 'INSERT INTO foo VALUES( NULL, ?, ? )' );
 for( $i = 0; $i < 1000000000; ++$i ) $sql->execute( Array( rand( 0, 1000000000 ), rand( 0, 1000000000 ) ) ); // wykonujemy miliard zapytań z losowymi danymi
 $db->commit(); // wykonujemy transakcje - w tym momencie zapytania zostaną wykonane
}
catch( PDOException $e ) { // coś poszło nie tak!
 $db->rollBack(); // wracamy do stanu sprzed transakcji ...
 // ...
}

Jak widzimy, funkcja rollBack odpowiada za wrócenie do ‘stanu początkowego’. Oczywiście, w transakcjach możemy wykonywać zapytania typu SELECT – nie ma to jednak większego sensu. Mechanizm ten został wymyślony raczej do zapytań w stylu CALL, INSERT, UPDATE czy DELETE FROM – i przy takich okazjach należy go używać. Niestety, wadą tego rozwiązania jest fakt, że nie działa na każdej bazie danych – mogę potwierdzić z doświadczenia, że działa na nowszych MySQL, SQLite3 i PostgreSQL – w innych nie mam pojęcia. PDO jest jednak tak sprytnie skonstruowane, że w przypadku braku obsługi tego mechanizmu funkcje nie będą nic robić. Zapytacie się więc – jak sprawdzić, czy baza na pewno wróciła do stanu początkowego? Prosto – rollBack zwraca TRUE lub FALSE, jeżeli się nie udało.

Podsumowanie:

Uważam, że PDO jest jedną z lepszych technologii, które przyszły wraz z obsługą obiektowości w PHP. Dopiero od PHP 5.x rozwinęła ona skrzydła i jest teraz o wiele lepszą alternatywą dla proceduralnego podejścia. Zwalnia programistę od sporej ilości rzeczy, które miał do uczynienia w przypadku starszych technologii, a które były żmudne i niestety niezbędne, gdy chodziło o bezpieczeństwo strony – chodzi tutaj o zabezpieczenie przed atakami SQL Injection. W przypadku zapomnienia lub pomyłki taki atak mógłby mieć opłakane skutki – chociażby wykradnięcie całej bazy danych maili użytkowników to ogromna gratka dla wszelkiego rodzaju spambotów. Dzięki prepared statements ten problem znika – wewnętrzne mechanizmy PDO radzą sobie z bezpieczeństwem znakomicie.

Mam nadzieję, że tym artykułem zachęcę Was do używania PDO w swoich małych lub większych projektach!

Pozdrawiam

Killavus

Wracając do tematyki notki – co się stanie gdy wywołanie fukncji systemowej np. write przerwie nam sygnał który dotarł do programu? W większości przypadków funkcja wykona część lub nie wykona operacji w ogóle, ale bez problemowo można ją wywołać ponownie, a zmienna errno zostanie ustawiona na mistyczną juz wręcz wartość EINTR. Niestety funkcja connect tak nie działa. Gdy zwrócony zostanie niezwykle tajemniczy błąd EINTR to nie możemy wywołać jej ponownie. Logiczne, prawda?

Więc co możemy zrobić?

Tak naprawdę łączenie nie zostaje przerwane – odbywa się dalej, asynchronicznie. Musimy tylko wiedzieć kiedy się skończy. W sumie warto by było.

Jak?

To bardzo proste i intuicyjne: należy wywołać funkcję select lub poll i przekazać im zamiar odczytania naszego socketa (uważając na EINTR!), potem należy odczytać opcje SO_ERROR (getsockopt) i sprawdzić czy wynosi 0. Wtedy możemy być na 99% pewni, że nasz socket jest podłączony. Kawałek kodu, co by nie być gołosłownym:

if(connect(socket, &addr, addrlen) == -1) {
    fd_set rset;
    int option;
    int optionlen;
    if(errno != EINTR) {
        /* Tu łączenie naprawdę się wywaliło. Serio. */
        perror("connect");
        exit(1);
    }
 
    FD_ZERO(&rset);
    FD_SET(socket, &rset);
    while(select(socket + 1, &rset, NULL, NULL, NULL) == -1) {
        if(errno != EINTR) {
            perror("select");
            exit(1);
        }
    }
 
    optionlen = sizeof(option);
    if(getsockopt(socket, SOL_SOCKET, SO_ERROR, &option, &optionlen) == -1) {
        perror("getsockopt");
        exit(1);
    }
 
    if(option != 0) {
        fprintf(stderr, "connect: %s", strerror(option));
        exit(1);
    }
}
 
/* Hurra! jesteśmy połączeni! */

Tak, powyższy kod robi dokładnie to samo co zwykły, stary, poczciwy, blokujący connect, który nie byłby przerwany sygnałem.

Miłego zagłębiania się w tajniki sztuki Uniksowej, życzy Sznurek.

Manual z wami.

Blogu – z informacjami od developerów, ciekawostkami technologicznymi, programistycznymi, o sieciach,

Sprawdzaczki – narzędzia, które umożliwi sprawdzenie poprawności algorytmów dla wielu zagadnień matematycznych,

Prace nad większością jeszcze trwają, cierpliwości – już niedługo wszystko będzie działać.

Nie zaprzeczamy, że w przyszłości projekt może zostać poszerzony o dodatkowe elementy – z pewnością tak się właśnie stanie.