2013/12/30 Bruno <[email protected]> > Le 30 décembre 2013 11:28, Pierre Equoy <[email protected]> a écrit : > > > Salut Bruno, > > > > tu peux donner le numéro de l'issue et/ou son URL ? > > > > (c'est juste par curiosité) > > > > Salut Pierre, > > Il s'agit du ticket #1912 : http://dev.dotclear.org/2.0/ticket/1912 >
Merci ! S'agit-il d'une régression, ou bien d'un problème qui aurait pu être détecté avant la 2.6 ? Tiens d'ailleurs, au niveau des tests, comment ça se passe à ce niveau là ? Est-ce qu'on a des tests unitaires qui peuvent être lancés sur commande (voire automatiquement) ? Si oui, est-ce que toutes les méthodes qui font appel à une base de données sont testées ? > > Pour le contexte, il n'y a pas vraiment de consensus au niveau de la > syntaxe SQL quand on veut faire un DELETE ou un UPDATE sur un table et > qu'on veut mettre une condition sur une table tierce, selon qu'on utilise > pgsql, mysql ou sqlite. > > Actuellement pour les commentaires dc, on veut s'assurer que quand on > modifie/supprime un commentaire, ils sont bien associés à un billet du blog > courant. Or l'information blog_id n'est pas présente directement dans > dc_comment, mais dans dc_post, il faut donc récupérer le billet du > commentaire et tester le blog_id de ce billet. > > Dans la version actuelle de dcBlos, on fait de la gymnastique entre les > syntaxes spécifiques de mysql et postgresql pour avoir une requête potable, > mais visiblement on a zappé sqlite qui n'a pas vraiment de syntaxe pour > gérer les jointures, à l'exception des requêtes imbriquées, lesquelles > fonctionnent aussi avec pgsql et mysql, d'où ma proposition de généraliser > cette dernière notation. > Si cela n'impacte pas (trop) les perfs, je ne vois pas où est le mal :) > > -- > Bruno > -- > Dev mailing list - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Pierre Equoy -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
