Ticket #1786 (closed enhancement: wontfix)
Support des "group by" dans dcBlog
Reported by: | bruno | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | module:core | Version: | dev |
Severity: | normal | Keywords: | |
Cc: |
Description
dcBlog::getPosts devient vite un cauchemar quand on cherche à intégrer un compteur et une jointure, notamment lorsque postgresql est bien moins tolérant là-dedans que mysql.
Il faudrait permettre d'ajouter des clauses group by autrement qu'à l'arrache dans $paramssql?,
A voir si c'est généralisable à d'autres méthodes qui permettent d'ajouter des colonnes à la requête SQL.
Change History
comment:2 Changed 7 years ago by franck
Yep, j'suis d'avis de pas trop casser getPosts, mais c'est vrai que cette fonction est devenue une vraie usine à gaz :-)
Surtout que la plupart vont coder ça pour MySQL et que ça va surement hurler pour PostgreSQL.
J'suis d'avis de réfléchir à ça, et éventuellement commencer à imaginer un wrapper un peu plus "générique" pour des accès un peu complexes à la base.
comment:3 Changed 7 years ago by nikrou
D'ailleurs dans la dernière version stable de mysql, par défaut le comportement des group by est le même que pour postgresql. Il suffit que les champs dans le group by soient aussi dans le select. Après pour que ce soit générique c'est une autre paire de manches !
En voulant résoudre le ticket #2206 je me suis rendu compte de ce manque (impossible de faire un LEFT JOIN ou NOT EXISTS ou NOT IN propre sans un GROUP BY derrière pour le tags par exemple), mais pas seulement, en effet j'ai déjà utilisé l'ajout de GROUP BY à l'arrache dans le params sql pour un plugin, imagine les dégâts si il y en a déjà un présent... On pourrait effectivement créer un params groupby mais il y a 95% de chances que ça ne marche pas tellement cette clause est peu permissive et la fonction getPosts compliquée...
Ou alors on l'ajoute et on voit à quelle vitesse on casse tout.