Zend FR

ramos · 16-06-2009 09:54:27

Bonjour,

J'ai passé quelques temps à faire des recherches hier, et j'en ai déduit (à priori) les choses suivantes :

Zend_Db_Table()->select n'est pas prévu pour gérer les jointures. On peut faire des jointures à deux conditions :
- soit on ne sélectionne aucune colonne de la table jointe (on utilise la jointure pour éliminer des champs uniquement)
- soit on fait $select->setIntegrityCheck(false); auquel cas on récupère un élément Zend_Db_Table_Row "corrompu", c'est à dire correspondant à la table de jointure donc inexistante réellement : impossible de réutiliser l'élément (modification puis update par exemple).

Ce qui aurait été bien, ce serait d'obtenir un objet de type Zend_Db_Table_Row dont un paramètre (la clé étrangère) est un lien vers un second Zend_Db_Table_Row, aucun des deux n'étant corrompu. Mais ce n'est pas comme ça que fonctionne le composant.

Enfin, dernière possibilité : vous pouvez faire la requête sans jointure, puis utiliser sur chaque Zend_Db_Table_Row obtenu la méthode findParentRow. Problème, ce faisant, on multiplie les requêtes et la performance va en prendre un sacré coup.

La documentation de Propel (qui gère ce problème) en parle ici : http://propel.phpdb.org/trac/wiki/Users … tedObjects, mais installer propel sur le Zend Framework a pas l'air facile et Propel a ses propres inconvénients je pense...

En résumé, dès qu'il y a une jointure, je pense qu'il est préférable d'oublier Zend_Db_Table et de directement utiliser Zend_Db_Select pour construire la requête puis créer son propre modèle objet relationnel (MOR) à partir du résultat des requêtes. C'est plus de boulot et je trouve dommage que Zend n'ai pas prévu un vrai MOR avec Zend_DB, mais uniquement des objets Zend_Db_Table_Row sans relation directe.

Voilà le fruit de mes recherches, mais je me suis peut être trompé : qui peut confirmer ce que je viens de dire, ou me contredire en proposant une solution qui fonctionne, sachant que mon objectif c'est d'obtenir un MOR avec des relations directes entre les objets pour les sérialiser et les envoyer à Flex avec Zend_Amf.

Dernière modification par ramos (16-06-2009 09:56:28)

Mr.MoOx · 17-06-2009 10:47:25

- soit on fait $select->setIntegrityCheck(false); auquel cas on récupère un élément Zend_Db_Table_Row "corrompu", c'est à dire correspondant à la table de jointure donc inexistante réellement : impossible de réutiliser l'élément (modification puis update par exemple).

Perso j'ai un système d'autojointure (tiré de là http://sekaijin.ovh.org/?p=21 ) et en utilisant sur ma Row principal $row->setReadOnly(false) je peux la modifier et la sauvegarder. Mais impossible de faire ça sur les champs "jointés"...

ramos · 18-06-2009 11:18:33

Pour ceux qui aiment l'anglais, j'ai trouvé des éléments de réponse très intéressants ici et surtout à l'instant ici.

Attention, il n'y a pas de code tout fait là bas, c'est des réflexions assez poussées sur la séparation du modèle relationnel (la base de donnée) et du modèle métier (les objets qu'on va passer à la vue : dans mon cas les objets que je veux envoyer à Flex en les sérialisant avec Zend_Amf).

Enfin, pour revenir sur le nouveau QuickStart du Zend framework de la version 1.8 : certains se demandent sur ce forum l'intérêt d'avoir un Mapper pour justement séparer le relationnel du métier. Les deux liens que j'ai donné l'expliquent clairement.

Pour vous faire gagner du temps, le premier blog parle d'utiliser le pattern Gateway, qui sépare métier et relationnel, mais reste pas terrible parce que les objets sont directement manipulables via eux même (on peut faire $user->save() par exemple). C'est pas terrible parce que avec Zend_Amf par exemple, je vais sérialiser un objet qui contient des méthodes non sérialisables...

A l'inverse, le second blog parle d'utiliser le pattern Mapper qui sépare mieux les objets métier et leur manipulation : on doit faire $mapper->save($user).
Là mon objet User est complètement indépendant du reste, je peux le sérialiser sans risque. Ce second blog semble avoir inspiré le QuickStart actuel du ZF, puisque ZF suggère l'utilisation du Mapper.

Voilà, j'espère que ça intéressera quelqu'un, moi ça ma beaucoup aidé et ça ma donné la solution pour mes problèmes de jointures.

Zend FR

#1 16-06-2009 09:54:27

[Zend_Db_Table] Jointure et optimisation : question

#2 17-06-2009 10:47:25

Re: [Zend_Db_Table] Jointure et optimisation : question

#3 18-06-2009 11:18:33

Re: [Zend_Db_Table] Jointure et optimisation : question

Pied de page des forums