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.

Non esistono molti Object Relational Mapping layers in PHP5 di una certa solidità. Nel post vengono considerati i due ORM più famosi:

• Propel è un ORM che permette l’accesso al database usando un insieme di oggetti, mette a disposizione delle API per scrivere e leggere i dati. Propel permette allo sviluppatore di lavorare con il database nella stessa maniera con cui si lavora con le altre classi e oggetti in PHP.
• Doctrine è un ORM che si appoggia nella parte superiore del database abstraction layer. Una delle sue principali particolarità è la possibilità di scrivere query in una specie di dialetto SQL chiamato DQL. Questo permette allo sviluppatore di di sfruttare un’alternativa all’SQL per mantenere la massima flessibilità evitando la duplicazione del codice.

Viene inoltre considerato sfPropelFinder un plugin aggiuntivo per Propel che mette a disposizione una semplice API per lavorare con gli oggetti di Propel.La comparazione viene fatta analizzando il modo di agire in alcune situazioni ricorrenti del modello Article/Comment dei vari ORM.

Rimando all’originale per la lettura completa: Comparing Propel, Doctrine and sfPropelFinder.

symfony propel:build-all

che genera il model Propel e le classi dei form, oltre a

symfony generate:crud frontend

per creare l’interfaccia web per il list, create, update, e delete degli articoli. Buona lettura!