Il repository DoctrineExtensions prevede queste estensioni:

• Translatable
• Sluggable
• Timestampable
• Loggable
• Tree
• Sortable

I nomi sono piuttosto indicativi riguardo allo scopo di ognuna. Chi viene da symfony 1.x e doctrine 1.x ricorderà certamente una serie di plugin *ActAs* che avevano esattamente lo stesso scopo di queste estensioni.

Come detto, per utilizzare questi comportamenti in progetti symfony2, è possibile usufruire del bundle StofDoctrineExtensionsBundle che mette a disposizione listener e configurazioni varie per semplificare l’integrazione all’interno del progetto.

In questo momento il bundle non sembra gestire l’estensione Sortable ma non ho ancora verificato se si tratta di una carenza di documentazione o di una reale mancanza nell’implementazione dell’estensione.

Nei prossimi post spiegherò come configurare e utilizzare correttamente ognuna delle estensioni disponibili con il bundle.

The Doctrine 1.2 support seems to be extended to June, 1st 2011. But this post was written 11 months ago and I think the end of support was shortened…

Che affiancata al fatto che il supporto ufficiale a Symfony 1.x finirà il 31 dicembre 2012, fa evidenziare come per circa 1 anno e mezzo nessun ORM sarà ufficialmente supportato dal framework.

Che sia arrivato il tempo, per i progetti basati su symfony 1.x, di dare di nuovo un occhio a Propel?

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.

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:

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. Ricordo che questa NON È 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!

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

$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.

1
2
3
4
5
6
7

$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 (né alias) ‘a’ definita nel modello mi sono girato un po’ 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

1
2
3
4
5
6
7
8

...
$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();
...

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

1
2
3

$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’

1

$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!