Classe de simplification des SELECT

[bruno]

La manière de gérer les select SQL dans le code est parfois assez spartiate, surtout dans la construction linéaire de la requête : on est parfois forcé de faire 2 fois le même test, une fois pour ajouter un "INNER JOIN" après le from, une autre fois pour ajouter une clause WHERE. Sans compter le nombre de fois où on oublie l'espace final et où la requête foire...

Ca vaudrait le coup de se simplifier la vie avec une petite classe utilitaire qui construit la requête SQL en mode déstructuré (top chef, quand tu nous tiens :)

Dans l'idée, on ferait désormais :

$st = new SelectStatement();
$st->addColumn(array('P.post_id','P.post_selected'));
$st->addFrom($core->prefix."post");
$st->addWhere('P.post_selected=1');
$st->addFrom('INNER JOIN '.$core->prefix.'category C on C.post_id=P.post_id')

$rs = $con->select($st->getStatement());

[Moe]

Cette syntaxe me rappelle un projet déjà existant, tu veux ré-implémenter des  fonctions de  Doctrine2 ? :)

Je n'ai pas compris ton exemple, il ne contient aucun test alors que tu dis que les tests sont problèmatiques ? L'idée c'est que le dernier $st->addFrom(...); peut être ajouté ou non en fonction d'un test ?

[bruno]

Oulà non, je ne veux pas aller si loin, la classe en question est superbasique, et getStatement se contente de faire des concaténations et des join() php :)

Si tu regardes dcBlog::getPosts, on y construit la requête sql au fil de l'eau, en l'enrichissant en fonction de paramètres donnés dans $params. Sauf qu'actuellement c'est très séquentiel, on ne peut pas ajouter un inner join ou une colonne si on a déjà ajouté un where dans la chaîne. Par exemple on y teste 3 fois si $count_only est positionné, une fois pour les colonnes, une autre fois pour le limit, et une autre fois pour le order. Avec le selectStatement, on teste une seule fois $count_only, et on positionne le limit, le columns et le order en 3 lignes successives, c'est plus simple à lire :)

[nikrou]

Je te mets atoum sur la branche default. Tu fais un jeu d'essai pertinent et les tests qui vont avec.

Et après pour que cela ait un réel intérêt il faudrait que ce soit générique ce SELECT. Non ?

[franck]

SQL query builder en place côté Clearbricks, à compléter en vue de le simplifier, mais le plus gros est fait. Ça gère SELECT, INSERT, UPDATE et DELETE

Reste à voir comment encapsuler ça côté Dotclear pour rendre ça plus lisible qu'actuellement.

[franck]

Finalement SQL query builder supprimé de Clearbricks, on va faire plus simple…

[franck]

Merci Bruno pour le bout de code (cf [3740]), ça va bien aider :-)

[franck]

La classe est codée, on va s'arrêter là pour l'instant (cf [3740], [3741], [3742], [3743], [3747], [3748], [3749] et [3754])

[franck]

J'ai ouvert une branche spéciale pour avancer là-dessus : sql-statement (voir [3761])