Permettre de supprimer les fusions (group by) explicitement #3209

Closed
opened 8 years ago by rastapopoulos · 11 comments
Owner

Certaines boucles ou critères du core, ou de certains plugins, comme GIS, ajoute par défaut des groupements aux requêtes SQL afin d'obptenir tel ou tel comportement par défaut. Très bien.

Mais il n'y a pour l'instant rien qui permet, à celleux qui font des squelettes, de dire au cas par cas, boucle par boucle, qu'illes ne veulent PAS ce group by (ou qu'illes en veulent un autre ce qui revient au même). En effet, le critère {fusion} actuel ne marche que champ par champ, et ne fait qu'ajouter à la suite de ce qui existe déjà.

Afin de ne rien casser et de permettre de faire ce qu'on veut, je propose un nouveau critère {fusion_supprimer} qui supprime tout groupement précédemment défini. On peut ensuite rajouter ou pas un ou plusieurs critère {fusion} à la suite si jamais on veut rédéfinir autrement.

function critere_fusion_supprimer_dist($idb, &$boucles, $crit){
	$boucles[$idb]->group = array();
}

Et pour l'utilisation :

Pour n'avoir aucun groupement :



Pour remettre à zéro puis définir explicitement ce qu'on veut :


Certaines boucles ou critères du core, ou de certains plugins, comme GIS, ajoute par défaut des groupements aux requêtes SQL afin d'obptenir tel ou tel comportement par défaut. Très bien. Mais il n'y a pour l'instant rien qui permet, à celleux qui font des squelettes, de dire au cas par cas, boucle par boucle, qu'illes ne veulent PAS ce group by (ou qu'illes en veulent un autre ce qui revient au même). En effet, le critère `{fusion}` actuel ne marche que champ par champ, et ne fait qu'ajouter à la suite de ce qui existe déjà. Afin de ne rien casser et de permettre de faire ce qu'on veut, je propose un nouveau critère `{fusion_supprimer}` qui supprime tout groupement précédemment défini. On peut ensuite rajouter ou pas un ou plusieurs critère `{fusion}` à la suite si jamais on veut rédéfinir autrement. <pre> function critere_fusion_supprimer_dist($idb, &$boucles, $crit){ $boucles[$idb]->group = array(); } </pre> Et pour l'utilisation : <pre> Pour n'avoir aucun groupement : <BOUCLE_truc(TRUCS){boucle_qui_predefinie_un_groupement}{fusion_supprimer}> </BOUCLE_truc> Pour remettre à zéro puis définir explicitement ce qu'on veut : <BOUCLE_truc(TRUCS){boucle_qui_predefinie_un_groupement}{fusion_supprimer}{fusion champ1}{fusion champ2}> </BOUCLE_truc> </pre>
Owner

Version cible mise à 3.2

**Version cible mise à 3.2**
Owner

Bon je suis dans un cas assez concret :


	[(#DATE|annee)]

Ça ne prend pas en compte la fusion parce que SPIP a ajouté un group by articles.id_article. Avant celui du critère fusion.

Bon je suis dans un cas assez concret : <pre> <BOUCLE_facette_annee(ARTICLES){id_mot=27}{fusion YEAR(date)}> [(#DATE|annee)]<br /> </BOUCLE_facette_annee> </pre> Ça ne prend pas en compte la fusion parce que SPIP a ajouté un group by articles.id_article. Avant celui du critère fusion.
Poster
Owner

Bon, 2 ans que je l'utilise régulièrement de temps à autre, je l'ai ajouté à Bonux pour le moment, du coup :
http://zone.spip.org/trac/spip-zone/changeset/98598

Bon, 2 ans que je l'utilise régulièrement de temps à autre, je l'ai ajouté à Bonux pour le moment, du coup : http://zone.spip.org/trac/spip-zone/changeset/98598
Owner
There is no content yet.
Poster
Owner
There is no content yet.
Owner

Une proposition de Cerdic , de faire un peu comme pour les critères tris :

  • que le core ajoute les group by dans une clé group_defaut (plutot que group)
  • les critères dans la clé group
  • l'écriture à la compilation prendrait la clé group si elle existe, sinon group_defaut.
Une proposition de Cerdic , de faire un peu comme pour les critères tris : - que le core ajoute les group by dans une clé `group_defaut` (plutot que group) - les critères dans la clé `group` - l'écriture à la compilation prendrait la clé group si elle existe, sinon group_defaut.
Poster
Owner

Ça ne change pas trop spécialement, car le core c'est bien peu de chose, et ça a plus tendance à se réduire qu'à augmenter. Par exemple le critère {gis} qu'on met sur d'autres objets (ARTICLES){gis} par exemple, c'est un critère, et il ajoute du group by. Mais du coup si toi ensuite tu veux faire des {fusion} perso que tu veux choisir, tu ne peux plus. Donc le critère de suppression est toujours aussi utile.

Ça ne change pas trop spécialement, car le core c'est bien peu de chose, et ça a plus tendance à se réduire qu'à augmenter. Par exemple le critère {gis} qu'on met sur d'autres objets (ARTICLES){gis} par exemple, c'est un critère, et il ajoute du group by. Mais du coup si toi ensuite tu veux faire des {fusion} perso que tu veux choisir, tu ne peux plus. Donc le critère de suppression est toujours aussi utile.
Owner

Version cible mise à 4.0

**Version cible mise à 4.0**
Poster
Owner

PR ici : #113

PR ici : https://git.spip.net/spip/spip/pulls/113
Poster
Owner

Statut changé à En cours

**Statut changé à En cours**
Owner

intégré par d048f309de
Statut changé à Fermé

intégré par https://git.spip.net/spip/spip/commit/d048f309de84979a7357081d9f2a7a304b5d0452 **Statut changé à Fermé**
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.