Jdbi: Décourager et déprécier la prise en charge de StringTemplate4

Commençons par un avis dans la documentation indiquant que le projet StringTemplate est inactif.

Je vais laisser les autres membres du projet se prononcer sur la question de la dépréciation de l'intégration ST de Jdbi. Personnellement, je pense que nous devrions continuer à le soutenir pendant au moins un petit moment. Nous venons tout juste de commencer à prendre en charge ST4.

Je pense que nous avons besoin d'une alternative. Ne pas avoir de moyen de créer des modèles complexes pour SQL est interdit. J'ai besoin de pouvoir partager des bits et des parties SQL entre différents modèles et de pouvoir factoriser des éléments communs dans les méthodes de modèle. Pour moi, supprimer stringtemplate me fait chercher un autre framework alternatif. Sinon, je serais obligé de créer des fichiers SQL avec beaucoup de duplication.

Ajoutons un NOTICE maintenant. Nous pouvons le déprécier une fois que nous aurons un remplaçant viable.

Quelqu'un a-t-il des moteurs de modélisation préférés qui s'intégreraient bien dans jdbi? J'ai utilisé un peu mustache et c'était bien, mais je suis loin d'être un expert...

Merci @jarlah , c'était un peu ce à quoi je m'attendais.

C'est dommage que StringTemplate soit négligé en amont, mais tant que les gens l'utilisent et que cela fonctionne, il n'y a aucune raison pour nous de retirer le support.

Nous avons été assez satisfaits de FreeMarker où je travaille. La moustache est également une bonne option.

D'accord avec @jarlah - une alternative est nécessaire. J'utilise également activement des modèles et la duplication sera massive sans ST. L'alternative doit être simple et expressive - ce que j'aime dans le ST actuel. J'ai utilisé Freemarker il y a longtemps et si je m'en souviens bien, cela n'a pas l'air simple pour les modèles SQL.

BTW Voici mon dernier problème avec ST, dois-je le poster ici avec un code de contournement au niveau d'intégration jdbi?

S'il existe une solution de contournement simple que jdbi peut faire sans trop compliquer les choses, nous l'envisagerions certainement.

Comment des templateEngines supplémentaires seraient-ils regroupés dans jdbi ? Ils apportent tous des dépendances externes que nous ne voulons pas dans core , et ni créer un module à 1 classe ni définir un \

IIRC stringtemplate a son propre module mvn, alors peut-être devrions-nous continuer à le faire? Cela semble de toute façon moins compliqué pour les utilisateurs que les dépendances facultatives.

Je serais intéressé par la contribution d'un moteur StringSubstitutor (si ce n'est pas déjà fait), et Moustache semble assez amusant à faire aussi.

S'il s'agit d'une classe unique autonome avec une seule dépendance <optional> , ou tout aussi légère, elle peut aller dans le noyau. Sinon, faisons tourner un module. Ma préférence était censée être une ligne directrice, pas une barre impossible à franchir :)

Cela romprait avec le modèle défini par le module stringtemplate4. Et je sais qu'en tant qu'utilisateur, je déteste un peu plus que d'avoir à jouer avec maven, en particulier les dépendances de mes dépendances...

Je vois que stringtemplate a un @UseStringTemplateEngine malgré l'existence de @UseTemplateEngine . Est-ce une chose de commodité souhaitable pour chaque moteur de modèle ou est-ce que nous préférons nous en tenir à l'annotation générique uniquement à partir de maintenant, sauf si nécessaire?

Personnellement, je préférerais qu'ils soient divisés en modules, de sorte que vous ne puissiez même pas voir une classe dans votre IDE sans ses dépendances incluses de manière transitive dans le chemin de classe. NoClassDefFoundError peut être une vraie douleur.

J'ai beaucoup travaillé avec freemarker dans le passé. Cela pourrait être une entreprise amusante de mettre en œuvre un soutien pour cela. Il n'est pas directement destiné à cela. Mais c'est possible. Il faut bien regarder les performances.

Je pourrais en faire un pic si rien d'autre

travaille actuellement dessus. Je ne vais pas ouvrir de pull request avant d'avoir une preuve de concept fonctionnelle raisonnable. Il y a un problème avec l'utilisation de la configuration, car le chargement du modèle n'est pas statique, il doit être dynamique. Ainsi, chaque modèle doit être chargé et mis en cache manuellement. J'ai cloné le module stringtemplate4 et renommé les classes, etc. Si quelqu'un est intéressé, je travaille sur la branche master de mon fork de jdbi.

Je pense que la situation qui a conduit à ce problème est une combinaison des éléments suivants :

• StringTemplate 4 fonctionne généralement exceptionnellement bien (prévisible sinon rien d'autre) dans une utilisation monothread
• StringTemplate 4 n'a pas été conçu avec un accent particulier sur l'utilisation simultanée, ce qui a conduit à des bogues difficiles à résoudre sans casser les utilisateurs existants, ils sont donc restés pour la plupart tels qu'ils étaient

Si un StringTemplate 5 était créé, je m'attendrais à ce que la concurrence sûre (et probablement l'immuabilité) joue un rôle important dans la conception de base.