Une régression par rapport à 1.8.2e :
La rubrique est associée à 2 mots dans groupe
<BOUCLE_A(RUBRIQUES) {racine}{type_mot=groupe}{titre_mot=mot1}>
Me retourne 2 occurrences comme si titre_mot passait à la trappe
tandis que
<BOUCLE_A(RUBRIQUES) {racine}{titre_mot=mot1}>
me retourne bien l'occurrence attendue
C'est une question délicate.
Cette nouvelle version de Spip automatise les "clés étrangères" en cherchant automatiquement les champs communs à deux voire plusieurs tables. Auparavant Spip ne le faisait qu'avec des critères ad hoc (comme ces 2-ci) au comportement très dérogatoire. On va maintenir la compatibilité pour ces critères mais ça demande un peu de réflexion si on veut ménager
l'avenir.
Déesse A.
Bon, il semblerait que cette fois ca repond ce qu'il faut sans que
ca grille titre_mot/type_mot par ailleurs.
Déesse A.
Déesse A. a écrit :
Une régression par rapport à 1.8.2e :
La rubrique est associée à 2 mots dans groupe
<BOUCLE_A(RUBRIQUES) {racine}{type_mot=groupe}{titre_mot=mot1}>
Me retourne 2 occurrences comme si titre_mot passait à la trappe
Bon, il semblerait que cette fois ca repond ce qu'il faut sans que
ca grille titre_mot/type_mot par ailleurs.Déesse A.
Effectivement, mais il y a maintenant un comportement différent de 1.8 lorsque l'on se contente de {type_mot=groupe}.
Là ou il y avait avant 1 seule occurrence, on en a maintenant autant que de mot-clés dans le groupe.
Je viens juste d'observer ça avec une boucle ARTICLES.
<BOUCLE_evcom(ARTICLES){age_relatif_redac > -388}{age_relatif_redac < 388}{par date_redac}{type_mot=_Agenda}>
Ah oui, c'est l'absence de GROUP BY, on en avait parlé ici entre autres:
http://article.gmane.org/gmane.comp.web.spip.devel/30497
il faudrait réussir à formaliser à quel moment on en a besoin, ce n'est pas évident.
Déesse A.
Déesse A. a écrit :
Quels seraient les cas ou l'on voudrait des doublons avec une boucle ?
Aucun, le pb est celui de la performance.
Pourquoi ne pas s'en tenir au comportement 1.8 ?
parce que http://article.gmane.org/gmane.comp.web.spip.devel/3055
Pour compléter les extraits de discussion postés par Fil, qq infos complémentaires.
Lorsqu'on fait une jointure entre la table principales indiquée par <BOUCLEx(TABLE)...> et une autre, il y a un risque de doublons des éléments de la table principale, ce qu'il faut absolument exclure et c'est le rôle du "group by". Ce qui est idiot, c'est que si le risque est en fait absent, ce "group by" provoque la création d'une table temporaire très couteuse. Spip < 1.9 ne proposait qu'une dizaine de jointures écrite en dur dans le code, et qu'il etait donc facile d'optimiser. A présent Spip propose des jointures automatiques qu'il faut pouvoir optimiser automatiquement.
Pour cela, le compilateur a besoin d'information sur les caractéristiques des tables.
Dans les cas qui nous occupent, les tables spip_mots_* et spip_auteurs_* devraient indiquer que les couples (id_mot,id_obj) et (id_auteur,id_obj) sont uniques, autrement
que ce sont les Primary key de ces tables, déclaration que Spip n'a jamais faite alors qu'en plus elle permettrait d'accéler les recherches sur ces tables.
La question qui se pose alors est de savoir si on rajoute ces déclarations, ce qui veut dire:
- une occupation mémoire supplémentaire prise par cet index nouveau;
- un gel du format de ces tables après cet ajout.
J'ajoute que d'apres
http://dev.mysql.com/doc/refman/5.0/en/alter-table.html
il ne devrait pas y avoir de pb lors du changement rétroactif de déclaration, quand bien meme ces tables comporteraient erronément des couples dupliqués.
Déesse A.
dans la doc indiquée je vois ce chapitre :
IGNORE is a MySQL extension to standard SQL. It controls how ALTER TABLE works if there are duplicates on unique keys in the new table or if warnings occur when strict mode is enabled. If IGNORE is not specified, the copy is aborted and rolled back if duplicate-key errors occur. If IGNORE is specified, only the first row is used of rows with duplicates on a unique key, The other conflicting rows are deleted. Incorrect values are truncated to the closest matching acceptable value.
donc pour la reprise soit tu ajoute ignore auquel cas les doublons sont supprimés soit tu ne le mets pas et là la reprise echoue ?
oui, mais de toutes façons le cas ne devrait pas arriver: ces tables sont censées ne pas contenir de doublons. Je signalais juste ça en cas de vieux bugs qui aurait pu mettre le bazar.
Déesse A.
Déesse A. a écrit :
Quels seraient les cas ou l'on voudrait des doublons avec une boucle ?
Aucun, le pb est celui de la performance.
Pourquoi ne pas s'en tenir au comportement 1.8 ?
parce que http://article.gmane.org/gmane.comp.web.spip.devel/3055
Pour compléter les extraits de discussion postés par Fil, qq infos complémentaires.
Lorsqu'on fait une jointure entre la table principales indiquée par <BOUCLEx(TABLE)...> et une autre, il y a un risque de doublons des éléments de la table principale, ce qu'il faut absolument exclure et c'est le rôle du "group by". Ce qui est idiot, c'est que si le risque est en fait absent, ce "group by" provoque la création d'une table temporaire très couteuse. Spip < 1.9 ne proposait qu'une dizaine de jointures écrite en dur dans le code, et qu'il etait donc facile d'optimiser. A présent Spip propose des jointures automatiques qu'il faut pouvoir optimiser automatiquement.
Pour cela, le compilateur a besoin d'information sur les caractéristiques des tables.
Dans les cas qui nous occupent, les tables spip_mots_* et spip_auteurs_* devraient indiquer que les couples (id_mot,id_obj) et (id_auteur,id_obj) sont uniques, autrement
que ce sont les Primary key de ces tables, déclaration que Spip n'a jamais faite alors qu'en plus elle permettrait d'accéler les recherches sur ces tables.La question qui se pose alors est de savoir si on rajoute ces déclarations, ce qui veut dire:
- une occupation mémoire supplémentaire prise par cet index nouveau;
qui serait compensée par une accélération des recherches, ce qui ne serait peut-être pas si mal...
- un gel du format de ces tables après cet ajout.
L'ajout impacterait-il les contribs existantes (select SQL...) ? Mais un gel est-il inconcevable pour le noyau ?
Pour cela, le compilateur a besoin d'information sur les caractéristiques des tables.
Dans les cas qui nous occupent, les tables spip_mots_* et spip_auteurs_* devraient indiquer que les couples (id_mot,id_obj) et (id_auteur,id_obj) sont uniques, autrement
que ce sont les Primary key de ces tables, déclaration que Spip n'a jamais faite alors qu'en plus elle permettrait d'accéler les recherches sur ces tables.La question qui se pose alors est de savoir si on rajoute ces déclarations
Bon, la 5950 intègre ces déclarations pour les tables spip_mots, et le compilateur produit un GROUP BY seulement quand il faut.
Déesse A.
Déesse A. a écrit :
Pour cela, le compilateur a besoin d'information sur les caractéristiques des tables.
Dans les cas qui nous occupent, les tables spip_mots_* et spip_auteurs_* devraient indiquer que les couples (id_mot,id_obj) et (id_auteur,id_obj) sont uniques, autrement
que ce sont les Primary key de ces tables, déclaration que Spip n'a jamais faite alors qu'en plus elle permettrait d'accéler les recherches sur ces tables.
Bon, la 5950 intègre ces déclarations pour les tables spip_mots, et le compilateur produit un GROUP BY seulement quand il faut.
ça corrige bien le bug. Coté perfs je ne mesure pas de changements sensibles :
######work sans cache
real 0m59.919s
user 0m0.060s
sys 0m0.180s
######work avec cache
real 0m18.311s
user 0m0.070s
sys 0m0.130s
######svn sans cache
real 1m10.512s
user 0m0.060s
sys 0m0.260s
######svn avec cache
real 0m21.645s
user 0m0.070s
sys 0m0.150s