Usiamo un semplice esempio per mostrare la strada sbagliata, che potrebbe sembrare la più logica non conoscendo Propel, e quella giusta. Ipotizziamo di avere una semplice tabella con due soli campi: “nome” e “numero”. Da questa tabella vogliamo estrarre solo i record che hanno un valore di “numero” compreso tra 11 e 20 (con estremi esclusi).

SELECT *
FROM table
WHERE numero > 11 AND numero < 20

La traduzione errata, più istintiva, è qualcosa di simile alla seguente:

$c = new Criteria();
$c->add(TablePeer::NUMERO, 11, Criteria::GREATER_THAN);
$c->add(TablePeer::NUMERO, 20, Criteria::LESS_THAN);
...

dove si pensa che ogni add vada ad aggiungere una condizione conbinandola alle altre con un AND. Tutto questo però è sbagliato visto che aggiungendo in questo modo più condizioni sulla stessa colonna “sovrascrive” le precedenti e lascia utilizzata solo l’ultima. L’ equivalente di:

SELECT *
FROM table
WHERE numero < 20

che di sicuro non è quello che vogliamo. Come fare allora? Bisogna ricorrere all’utilizzo degli oggetti di tipo Criterion usando il metodo Criterion::addAnd():

$c = new Criteria();
$criterion = $c->getNewCriterion(TablePeer::NUMERO, 11, Criteria::GREATER_THAN);
$criterion->addAnd($c->getNewCriterion(TablePeer::NUMERO, 20, Criteria::LESS_THAN));
$c->add($criterion);
...

In questo modo le due condizioni verranno prese in considerazione allo stesso modo e collegate con un AND. Abbiamo ottenuto l’interpretazione corretta. Per lavorare con l’OR basta cambiare il metodo utilizzato da $criterion->addAnd a $criterion->addOr.

Con oggi iniziamo un nuovo argomento, destinato a accompagnarci per un bel pò sulle pagine virtuali di questo blog: la realizzazione di un ORM (Object Relational Mapping) per PHP5.

Scopo dell’articolo odierno è di fornire un’introduzione teorica all’argomento che affronteremo in questa serie di post.

Prima di tutto, cosa si intende con ORM: Un ORM è un componente che detto in maniera semplicistica fa da filtro tra il programma vero e proprio ed i dati del database. Si occupa della manipolazione delle tuple del DB, astraendo i comandi e evitando al programmatore di dover andare ad accedere direttamente ai dati. Se utilizzate un ORM in pratica vedrete spesso scritte come queste

$comment->getID();

$post->getAuthor()->getName();

e molto meno come queste

$result = mysql_query("select id from comments");

$result = mysql_query("select name from posts inner join authors on posts.author_id = author.id");

A me sembra più comodo e pratico, credo anche a voi.

L’immagine in cima al post (cliccateci per l’originale più grande e leggibile) spiega com’è implementato tutto ciò nel framework symfony: Propel (un ottimo ORM, forse un pò prolisso nella sintassi) si appoggia su Creole (lo strato che fisicamente si collega al DB, fa le query ecc.) e rende trasparente l’accesso al database da parte del programmatore.

Per semplicità io includerò tutto in un unico componente, realizzato in classi e sfruttando le capacità di PHP5. Chiedo ai lettori di correggermi nel caso troviate degli errori (sono umano anch’io, e l’ORM lo realizzo man mano che scrivo gli articoli) e di darmi consigli, saranno tutti bene accetti.

Ho deciso che l’ORM utilizzerà solo MySQL, in quanto sinceramente ho poca esperienza con altri tipi di RDBMS, e essendo un prodotto “artigianale” non ha molto senso andare a sbattere la testa con problemi di scelta del gestore dati. Realizzerò il componente in modo tale sia più semplice possibile andare a sopperire a questa mancanza, magari aggiungendo un singolo file con le istruzioni necessarie.

Rimando alla voce di wikipedia (o alla più completa versione in inglese) per ulteriori delucidazioni sulla parte teorica.

Nel prossimo articolo (online presumibilmente tra pochi giorni) inizieremo a vedere la struttura vera e propria del componente, la gerarchia dei file e concluderemo la parte teorica.