Discussion :

[Madfrix]

Bonjour,

je suis en train de lire le tuto de Julien Pauli sur la présentation du ZF et notamment la gestion des dépendances (ce point là).

Ma première question concerne les instructions de ce type :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
$tblLivres = new Livres();
$monLivre = $tblLivres->find('978-2841773381')->current();

j'ai bien compris que le current() renvoie un ensemble de type 'row' mais pourquoi dans ce cas passer par un rowset puis le transformer en row ? Un fetchRow ne serait il pas plus approprié ici ?

Ma deuxième question est celle ci : j'ai a peu près bien compris les méthodes "magiques" find<tableClass>Via<IntersectionTableClass>(), find<tableClass>() et findParent<tableClass>() mais est-il possible de récupérer uniquement certains champs via ces méthodes et pas tous les champs de la table concernée ?

Enfin, j'ai une dernière question

Il est marqué :

Abuser des méthodes de récupération des dépendances va générer une charge insoutenable pour le SGBD. Ces méthodes sont là, mais en pratique on les utilise très très peu.

Quel est le problème ?

Si on défini et configure notre protected $_referenceMap, c'est justement et uniquement pour pouvoir faire ses opérations non ?

Merci de vos éclaircissements

[patbator]

Hello,

j'ai bien compris que le current() renvoie un ensemble de type 'row' mais pourquoi dans ce cas passer par un rowset puis le transformer en row ? Un fetchRow ne serait il pas plus approprié ici ?

Le find recherche sur la clé primaire, typiquement ce qu'il y a de plus rapide. Libre à toi d'utiliser un fetchRow.

Ma deuxième question est celle ci : j'ai a peu près bien compris les méthodes "magiques" find<tableClass>Via<IntersectionTableClass>(), find<tableClass>() et findParent<tableClass>() mais est-il possible de récupérer uniquement certains champs via ces méthodes et pas tous les champs de la table concernée ?

Les magiques sont des raccourcis vers des méthodes findDependentRowset, findParentRow, etc… qui elle permettent de passer un select pour préciser ce que tu veux.

Quel est le problème ?

Si on défini et configure notre protected $_referenceMap, c'est justement et uniquement pour pouvoir faire ses opérations non ?

Yep 100% d'accord, cependant comme tout raccourcis, les magiques masquent une complexité qui peut amener rapidement un codeur inattentif a fetcher énormément de données.
Je conseil donc de laisser tomber les magiques mais de continuer à utiliser les relations par les méthodes qui leurs sont dédiées en évitant de fetcher des données inutiles.
Pour te rassurer, j'utilise énormément les relations sans blem de perf.

[Madfrix]

Ok, merci pour toutes ces réponses.

Finalement, la méthode la plus rapide reste quelque chose comme ceci alors ?

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$result = $db->fetchAll($db->select()->join(...));

Dans ce cas de figure, est on obligé de définir $_referenceMap dans le modèle ?

[patbator]

Hello,

Si tu joins à là main, effectivement la déclaration des dépendances n'est plus utile.

Par contre, tu te prives de la possibilité de faire des trucs comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
$row->findDependentRowset(
									$dependentTable),
									null,
									$depndentTable->select()
														->order('order_field DESC')
														->limit(1)

Comme je te disais, des méthodes basées sur les liaisons existent.

[manuscle]

Salut!

Justement je me pose cette question de performance mysql car j'hésite entre faire une requête avec multi jointures ou utiliser les magiques, j'explique mon cas:

J'ai un article avec plusieurs traductions, donc une table articles(id_article, id_categorie etc...) et une table articleLang(langue, id_article, titre) qui contient les trads dans chaque langue.
Seulement tout les article ne sont pas traduits, j'ai besoin de lister les articles avec ou sans trad.

Si je fait une requete avec jointure elle ressemblera à ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$select = "SELECT a.* FROM articles AS a LEFT JOIN articlesLang AS al ON al.id_article = a.id_article WHERE langue = 'en'

Le probleme est que si je n'est pas de traduction je n'est pas de ligne de resultat mais j'aimerais en avoir une dans la langue par defaut (fr) ou avec des champs vides. Je ne sais pas comment faire en Mysql mais peut etre y a t-il une solution ?!.

Alors j'ai testé en passant par les classes de table:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
// Table articles
$TArticles = new TArticles();
// Table articlesLang
$TArticlesLang = new TArticlesLang();
 
$article = $TArticles->fetchAll();
foreach ($articles as $article) {
    $select = $TArticle->select()->where('langue LIKE ?', 'en');
    $articleLang = $article->findDependentRowSet('TArticlesLang', null, $select)->current();
 
    // Pas d'anglais, on cherche dans la langue par defaut (fr)
    if(!$articleLang) {
        $select = $TArticle->select()->where('langue LIKE ?', 'fr');
        $articleLang = $article->findDependentRowSet('TArticlesLang', null, $select)->current();
    }
 
    // Pas de langue par defaut, on crée un row vide en lecture seule
    if(!$articleLang) {
        $articleLang = $TArticlesLang->createRow();
        $articleLang->setReadOnly(true);
    }
     echo $article->id_article . ' => ' . $articleLang->titre . '<br />';
}

C'est plutot assez gourmand comme code mais l'avantage est que je conserve les objets et j'ai des champs vides. Est-ce une solution interressante ou y-a-t-il mieux?

[patbator]

Wow,

Une boucle sur un fetchAll qui fait des sous-requêtes , j'espère que tu es sur que le fetchAll ne va pas te renvoyer trop de résultats, sinon bye bye les perfs !

Ensuite, je te conseil dans des cas comme ça de ne pas faire un like sur la langue mais une simple égalité + un index sur ton champ de langue.

Enfin, pour les trads de mes données j'ai mis en place un code centralisé capable de joindre automatiquement la table de trad sur 1 Zend_Db_Select.

Le left join ne devrait pas exclure les lignes de la table de gauche qui n'ont pas de correspondance dans la table de droite.