[spip-dev] boucles sur les documents : trop lourdes ?

Question peut-être stupide, mais j’aimerais connaitre l’objectif de certaines jointures :

Pourquoi est-ce qu’une boucle
<BOUCLE_listdoc1(DOCUMENTS){id_article}>

ne génère pas un code aussi simple qu’une boucle
<BOUCLE_listdoc2(DOCUMENTS_LIENS spip_documents){objet=‘article’}{id_objet=#ID_ARTICLE}>

?

La première boucle est devenue une vrai usine à gaz.

Voici les requêtes générées :
<BOUCLE_listdoc1> :
SELECT spip_documents.id_document, spip_documents.fichier, spip_documents.largeur, spip_documents.hauteur, spip_documents.titre
FROM spip_documents AS spip_documents LEFT JOIN spip_documents_liens AS l
ON spip_documents.id_document=l.id_document
LEFT JOIN spip_articles AS aa
ON (l.id_objet=aa.id_article AND l.objet=“article”)
LEFT JOIN spip_breves AS bb
ON (l.id_objet=bb.id_breve AND l.objet=“breve”)
LEFT JOIN spip_rubriques AS rr
ON (l.id_objet=rr.id_rubrique AND l.objet=“rubrique”)
LEFT JOIN spip_forum AS ff
ON (l.id_objet=ff.id_forum AND l.objet=“forum”)
INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = spip_documents.id_document )
WHERE ((aa.statut = “publie”) OR bb.statut = “publie” OR rr.statut = “publie” OR ff.statut=“publie”)
AND (spip_documents.mode != ‘vignette’)
AND (spip_documents.taille > 0 OR spip_documents.distant=‘oui’)
AND (L1.id_objet = 7)
AND (L1.objet = ‘article’)
GROUP BY spip_documents.id_document

et

<BOUCLE_listdoc2> :
SELECT documents_liens.id_document, L1.fichier, L1.largeur, L1.hauteur, L1.titre
FROM spip_documents_liens AS documents_liens
INNER JOIN spip_documents AS L1 ON ( L1.id_document = documents_liens.id_document )
WHERE (documents_liens.id_objet = 7)
AND (documents_liens.objet = ‘article’)

Dans la première requête, on sait que notre objet est un article (cf. code en fluo).
Donc pourquoi le rechercher dans les breves, rubriques, forums ?

.Gilles

Pourquoi est-ce qu'une boucle
<BOUCLE_listdoc1(DOCUMENTS){id_article}>

.../...

La première boucle est devenue une vrai usine à gaz.

Oui ça a été fait d'ajouts et d'ajouts supplémentaires. Tout ça parce
qu'on n'a pas de champ statut dans spip_documents (note : faire un
patch)

-- Fil

C'est déjà fait dans le plugin gestion_documents, dans lequel je suis en train de refaire toute la gestion des documents, et que je compte bine intégrer au _core_/plugins ensuite.

J'ai mis en place un champ statut calculé, et une date de publication.
A chaque publication/dépublication d'un objet le plugin met a jour le champ statut des documents liés, en prenant pour chaque document le statut 'le plus publié' parmis tous les objets auquel le document est lié.
C'est à dire que, par exemple, si le document est lié à un article 1 publié dans le futur et un article 2 proposé, le document sera publié dans le futur à la même date que celle de l'article 1.

Il y a un petit soucis par contre :
- comme la gesiton des docs est en plugin, si jamais on desactive le plugin, publie un article et réactive le plugin, on a perdu la synchro entre l'article publié et ses documents.

Cela m'amène à penser qu'il faut pour les plugins un trig d'activation (on a actuellement uniquement installation/desinstallation), qui permettrait au plugin de re-vérifier les status de ses documents à ce moment là.

Idéalement, j'ai déjà rencontré des cas ou un trig de désactivation serait bien, mais on ne peut pas le garantir, notamment dans le cas où le plugin est renommé sauvagement pour forcer sa désactivation.

Pour en revenir à la gestion des documents, le projet est bien avancé puisque toute la colonne document (sur les articles en édition) est refaite, et il ne me reste plus que
- le portfolio (sous les articles en visu) à refaire (ce qui n'est pas le plus dur)
- la réimplémentation d'une interface pour les retouches (rotation, resizing?) des images

J'aurais aimé aussi réintégrer toute la gestion des logos et logos survol dans la table documents, mais on fera peut être cela en deux étapes...

Pour l'instant, je développe sur la base 2.0.x et j'ai procédé par surcharges, du coup le plugin ne tourne plus sur la 2.1 en ce moment. Il faut donc le tester avec la version stable.

Cédric