Symfony-IT » orm

test complessi con sfTesterDoctrine

garakkio — Mon, 26 Jul 2010 09:23:28 +0000

A volte può capitare di dover testare delle condizioni complesse su un oggetto Doctrine. In questi casi, il semplice array solitamente usato col metodo check() può non bastare. Per esempio mi è capitato recentemente di dover testare alcuni campi data con una condizione >= (maggiore o uguale).
Ma lo stesso metodo check() è abbastanza flessibile da accettare come secondo parametro non solo un array, ma anche un oggetto Doctrine_Query. Basterà quindi costruire le condizioni in questo modo e passarle, e il gioco è fatto.

Propel in Symfony 2.0

garakkio — Mon, 24 May 2010 07:35:24 +0000

Sembra che la tanto attesa nuova versione di Symfony supporterà, come l’attuale, entrambi gli ORM. Se infatti Doctrine, ormai legato a doppio filo al framework, non è mai stato in dubbio, Propel sembrava rimasto indietro. Invece, pochi giorni fa, l’instancabile François Zaninotto ha pubblicato il suo fork con PropelBundle.

È uscito Propel 1.5

garakkio — Mon, 26 Apr 2010 11:42:27 +0000

L’atteso rilascio della nuova versione di Propel è ufficiale proprio oggi. La novità maggiore è nella nuova API di oggetti Query, che si rifanno in parte a quelli di Doctrine, ma usando un’interfaccia fluida invece di un linguaggio pseudo-SQL. Ci sono inoltre nuovi behavior e l’ereditarietà concreta per le tabelle. Il tutto è stato mantenuto retrocompatibile con la versione 1.4. Già da ora è possibile usare Propel 1.5 in un progetto symfony, grazie a sfPropel15Plugin.
Ecco la lista completa delle novità.

“Di più con symfony” su Amazon come presente per l’anno nuovo!

fullo — Wed, 30 Dec 2009 15:03:12 +0000

È ufficialmente disponibile su Amazon, la nuova traduzione italiana dell’advent calendar intitolato More with Symfony e rilasciato agli inizi di dicembre in formato digitale in più lingue e cartaceo nella sola lingua inglese.

Il libro approfondisce argomenti come il routing, la nuova gestione delle email di symfony 1.4, gli internals di symfony e come estendere Doctrine.

Il libro è stato tradotto dalla comunità italiana di Symfonisti che si è prodigata per renderlo disponibile immediatamente insieme alla versione ufficiale.

Propel 1.4 è qui

garakkio — Mon, 05 Oct 2009 06:44:34 +0000

Come annunciato in precedenti post, Propel è risuscitato. La prima mossa, di pochi giorni fa, è stata la partenza del ramo 1.4, che ha iniziato con l’implementazione dei comportamenti (behaviour), del tutto simili a quelli di Doctrine. Già in symfony 1.3 avremo l’opportunità di vederlo in azione, mentre per i progetti ancorati a symfony 1.2 c’è un apposito plugin.

IRC Meeting per il futuro di Propel

fullo — Tue, 08 Sep 2009 10:12:36 +0000

François Zaninotto e Sven Teitje, che hanno ufficialmente annunciato di aver preso in carico il progetto Propel con la mail qui di seguito, hanno indetto un IRC meeting per discutere del futuro dell’ORM.

Se avete qualche idea interessante, e voglia di comunicarla, l’appuntamento è sul canale #propel di Freenode il 10 Settembre alle 20.00.

Dear Propel devs / users,

Hans Lellelid, current lead of the Propel project, has agreed to leave the
project keys to François Zaninotto (for the 1.x branch) and Sven Teitje (for
the 2.x branch). Both François and Sven will do their best to help Propel
get better and get more users.

And because you probably all have lots of ideas, an IRC meeting is planned
on the #propel channel on freenode on Thursday, September 10th, at 8:00pm
West European Time (that’s 2:00pm East Coast time). Please come there to
explain your needs, offer your collaboration, discuss the project
management, and meet the new project leaders. If you can’t make it for the
IRC meeting, don’t hesitate to use the propel development mailing-list (

http://groups.google.com/group/propel-development).

François Zaninotto (francois) and Sven Teitje (tiddy)

Propel è morto. Evviva Propel.

fullo — Thu, 03 Sep 2009 17:26:12 +0000

Pare che il celeberrimo ORM non stia vivendo un bel periodo, infatti dopo una serie di messaggi su possibili problemi con PHP 5.3, Hans Lellelid (principale autore ed attuuale lead developer del progetto) ha ufficialmente annunciato che abbandonerà la sua creatura.

Fortunatamente però pare che Francois Zaninotto, già famoso per il il lavoro fatto sulla prima versione di symfony e di molta della sua documentazione, e Sven Tietje prenderanno in mano il tutto.

Non si sa però come e con quali modalità continuerà lo sviluppo di questo ORM, per ora quindi non ci resta che aspettare.

Usando symfony 1.2 e Doctrine 1.0 problemi con le equal nested relation

filippo — Tue, 02 Jun 2009 20:55:13 +0000

Non so se vi è mai capitato di avere a che fare con le cosiddette "equal nested relation". Queste relazioni tra oggetti sono quelle relazioni che possono essere tradotte (per quanto riguarda il database) con un "auto join" su una stessa tabella.

Un esempio pratico lo potete trovare fra gli esempi del sito dell'ORM Doctrine : Equal Nested Relation.

In uno dei miei progetti (Symfony 1.2, Doctrine 1.0) ho dovuto usare un esempio analogo, ma invece che utenti collegati fra loro con una relazione molti a molti, dovevo collegare più ticket. Una volta messo tutto in piedi e creato le classi necessarie ho fatto qualche prova e mi è spuntato questo errore:

PLAIN TEXT

CODE:

500 | Internal Server Error
Doctrine_Connection_Mysql_Exception SQLSTATE23000: Integrity constraint violation: 1062 Duplicate entry 'N-N' for key 1

Inizialmente ho cercato una soluzione che potesse dipendere dalle configurazioni del file schema.yml che usavo e poi soluzioni che potessero riguardare qualsiasi altra cosa. Dopo quasi due giorni a sbattere la testa su questo problema sono andato al PHPDay2009 a cui avrebbe partecipato anche Jonathan Wage, ovviamente ripromettendomi di chiedere direttamente a lui!!

Fortunatamente c'è stata occasione di parlargli e Jonathan è stato più che gentile tanto da aiutarmi e mettersi a provare a trovare una soluzione lì per lì per il mio problema. Dopo circa un'ora siamo arrivati a capire dov'era il problema. Poi a pezzi e bocconi siamo arrivati ad una soluzione nelle successive 24 ore!

La patch da utilizzare è scaricabile da qui. Ricondo che questa NON E' UNA SOLUZIONE DEFINITIVA. E' piuttosto un workaround al problema!! Un ticket relativo a questa soluzione è stato aperto qui.

Sembra che questo problema sia risolto utilizzando symfony 1.3 e doctrine 1.1, quindi aspettiamo con ansia la prossima uscita di symfony che include sfDoctinePlugin con doctrine 1.1!

Symfony, Doctrine e validatori

filippo — Thu, 16 Apr 2009 09:30:42 +0000

Ultimamente mi è capitato di lavorare con Doctrine all'interno di un progetto Symfony e di dover validare dei campi in input rispetto ad una classe del mio modello. Per particolari accorgimenti nella selezione degli input accettati mi sono trovato di fronte ad un problema che mi ha fatto perdere un pò di tempo e che non sono riuscito a capire subito da cosa dipendesse. Lo segno qui per chi si trovasse nella mia stessa situazione.

Per la validazione degli input ho utilizzato sfValidatorDoctrineChoiceMany, che già valida gli input rispetto ad una classe del modello

PLAIN TEXT

CODE:

$this->validatorSchema['users_list'] = new sfValidatorDoctrineChoiceMany(array('model' => 'User');

La particolarità a cui mi sono trovato di fronte è quella in cui i valori accettati in input dovevano essere validati rispetto ad un sottoinsieme di quelli contenuti nel mio modello. Seguendo la guida trovata sul sito di symfony aggiungo il parametro 'query' al mio validatore.

PLAIN TEXT

CODE:

$q = Doctrine_Query::create()
->from('User u')
->where('u.name = '.$name);
...
$this->validatorSchema['users_list'] = new sfValidatorDoctrineChoiceMany(array('model' => 'User' ,'query' => $q));

A questo punto però mi sono trovato di fronte all'errore

500 | Internal Server Error | Doctrine_Exception

Couldn't find class a

Non avendo nessuna classe (ne alias) 'a' definita nel modello mi sono girato un pò i log che vengono forniti da symfony e ho scoperto che sfValidatorDoctrineChoiceMany, durante il cleaning dei valori in input, esegue la query aggiungendo un'opzione al 'where':

sfValidatorDoctrineChoiceMany.class.php

PLAIN TEXT

CODE:

...
$a = $this->getOption('alias');
$q = is_null($this->getOption('query')) ? Doctrine_Query::create()->from($this->getOption('model') . ' ' . $a) : $this->getOption('query');
$q = $q->andWhereIn($a . '.' . $this->getColumn(), $values);
$objects = $q->execute();
...

Queto comportamento è giusto per il classico meccanismo di doctrine di inserire un alias quando si esegue una query del tipo

PLAIN TEXT

CODE:

$this->status_list = Doctrine::getTable('User')
->createQuery('a')
->execute();

ma non lo è quando si genera una query leggermente più complessa.

La soluzione di questo problema è molto semplice ma non così banale, almeno dal mio punto di vista. Basta infatti aggiungere al validatore l'opzione 'alias'

PLAIN TEXT

CODE:

$this->validatorSchema['users_list'] = new sfValidatorDoctrineChoiceMany(array('model' => 'User', 'alias' => '' ,'query' => $q));

Spero che questo appunto possa darvi una mano se mai vi troverete di fronte alla mia stessa situazione.

Buono "sviluppo" a tutti!