SqlBuilder, c’est bien !

Bon, j'ai l'impression que ça fait bien longtemps que je n'ai pas parlé de Java ici … (en l'occurence, ça date du mois de juin), il est donc temps de réparer cet oubli.
Mais avant, un petit détour du coté de groovy sera utile.

Petit voyage au pays des Builders

En Groovy, donc, il y a un concept qui est bien, et dont je me sers avec plaisir, c'est celui des Builders. Un Builder, c'est un objet dans lequel on déclare ses éléments, et qui les construit à la volée. Il y en a plein et, souvent, ils permettent d'écrire les choses d'une façon très compacte. Ce concept, on le retrouve évidement en JavaFX, où il s'agit de la seule façon d'instancier les objets, en fait.
C'est un concept tellement bien que, la plupart du temps (et même si ça n'est malheureusement pas possible) j'essaye d'utiliser des APIs qui fournissent ce genre de constructions.
Et cette semaine, je suis tombé sur deux candidats dans un domaine qui me paraît essentiel, mais pour lequel je vais faire un autre détour.

SQL, le faux ami

En fait, dans une application Java, bien trop souvent (hélas, pour ceux comme moi qui trouvent le SQL décidément trop archaïque), on a besoin d'écrire du SQL. le SQL, c'est un peu la lingua franca des bases de données relationnelles. Elles le comprennent toutes à peu près de la même manière (et ajoutent toutes leurs petites extensions plus ou moins bien pensées), bien qu'il existe une norme le définissant totalement. Bon, ça, c'est gênant, mais pas trop. Ce qui est beaucoup plus gênant, c'est que le SQL est un langage interprété. C'est-à-dire qu'on sait qu'une instruction SQL est valide seulement en l'exécutant. Parce qu'à part ça, mis à part avec des extensions au langage, ça n'est qu'une chaine de caractère qu'on stocke dans un fichier de propriétés (certains mettent directement ce SQL dans une chaîne de caractère dans le code Java, mais c'est plutôt moyen).
On stocke donc le SQL quelque part, en espérant que ce SQl est valide au sens de la syntaxe, mais en sachant qu'on ne pourra vérifier ça qu'avec un test unitaire, alors que bon, le vérifier dés la compilation serait quand même vachement plus pratique, non ?

SQLBuilder à la rescousse !

Ben oui, évidement, c'est à ça que sert le SQLBuilder ! A écrire du code Java qui va produire comme résultat une requête SQL, certes dans une chaîne de caractère, mais dans une syntaxe garantie correcte au sens du langage ! Et coup de bol, il en existe deux (trouvés évidement sur StackOverflow) :
Evidement, vu le titre de l'article, vous vous doutez bien que j'ai choisi le second. Et vous avez raison. Mais pourquoi ? Eh bien tout simplement parce que Squiggle se limite à faire des SELECT quand SQLBuilder fournit toutes les opérations. Et que je compte bien utiliser toutes ces opérations pour un projet pas trop secret, mais discret quand même.

My 2 cents

SQLBuilder est donc bien pratique, mis à part un petit point de "détail". Comme Squiggle, il ne peut travailler qu'avec des Table, Column et Schema déjà déclarés. Et quand par exemple on veut injecter les informations d'une table déjà existante, ça peut être un peu fastidieux de le faire à la main. J'ai donc écrit une petite classe qui permet de tout charger depuis une Connection JDBC.

Cette classe, la voici :

Et avec ça, croyez-moi, travailler avec SQLBuilder devient terriblement facile, parce que SQLBuilder connaît alors toutes les tables de la base de donnée, ainsi que toutes ses colonnes avec leurs information de type complet.
Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s