Jdbi: Entmutigung und Einstellung der Unterstützung von StringTemplate4

Beginnen wir mit einem Hinweis in den Dokumenten, dass das StringTemplate-Projekt inaktiv ist.

Ich überlasse den anderen Projektmitgliedern die Frage der Einstellung der ST-Integration von Jdbi. Persönlich denke ich, dass wir es zumindest eine Weile weiter unterstützen sollten. Wir haben gerade erst angefangen, ST4 zu unterstützen.

Ich denke, wir brauchen eine Alternative. Keine Möglichkeit, komplexe Vorlagen für SQL zu erstellen, ist ein No-Go. Ich muss in der Lage sein, SQL-Bits und -Teile zwischen verschiedenen Vorlagen zu teilen und in der Lage zu sein, allgemeine Dinge in Vorlagenmethoden einzubeziehen. Für mich bedeutet das Entfernen von stringtemplate, dass ich nach einem anderen alternativen Framework suche. Wenn nicht, wäre ich gezwungen, SQL-Dateien mit viel Duplizierung zu erstellen.

Fügen wir jetzt ein NOTICE . Wir können es verwerfen, sobald wir einen brauchbaren Ersatz haben.

Hat jemand Lieblings-Templating-Engines, die gut in jdbi passen würden? Ich habe mustache ein bisschen benutzt und es war in Ordnung, aber ich bin weit davon entfernt, ein Experte zu sein...

Danke @jarlah , so hatte ich es erwartet.

Es ist bedauerlich, dass StringTemplate im Upstream vernachlässigt wird, aber solange die Leute es verwenden und es funktioniert, gibt es keinen Grund für uns, die Unterstützung zurückzuziehen.

Wir waren ziemlich zufrieden mit FreeMarker, wo ich arbeite. Schnurrbart ist auch eine gute Option.

Stimme @jarlah zu - Alternative wird benötigt. Ich verwende auch aktiv Vorlagen und die Duplizierung wird ohne ST massiv sein. Alternative soll einfach und ausdrucksstark sein - was mir an aktuellen ST gefällt. Ich habe Freemarker vor langer Zeit verwendet und wenn ich mich richtig erinnere, sieht es für SQL-Templating nicht einfach aus.

BTW Hier ist mein letztes Problem mit ST, soll ich es hier mit Workaround-Code auf jdbi-Integrationsebene posten?

Wenn es eine einfache Problemumgehung gibt, die jdbi tun kann, ohne die Dinge zu sehr zu komplizieren, würden wir sie sicherlich in Betracht ziehen.

Wie würden zusätzliche TemplateEngines in jdbi gebündelt? Sie alle bringen externe Abhängigkeiten ein, die wir in core nicht wollen, und weder ein 1-Klassen-Modul erstellen noch ein \

IIRC Stringtemplate hat jedoch ein eigenes mvn-Modul, also sollten wir das vielleicht einfach weiter machen? Es klingt sowieso weniger nach einem Hacker-Problem für Benutzer als nach optionalen Abhängigkeiten.

Ich wäre daran interessiert, eine StringSubstitutor-Engine beizutragen (falls ich dies noch nicht getan habe), und Moustache scheint auch ziemlich Spaß zu machen.

Wenn es sich um eine eigenständige einzelne Klasse mit einer einzigen <optional> Abhängigkeit oder ähnlich leicht handelt, kann sie in den Kern integriert werden. Ansonsten lassen Sie uns ein Modul hochfahren. Meine Vorliebe sollte eine Richtlinie sein, keine unmögliche Messlatte :)

Dies würde jedoch mit dem vom stringtemplate4-Modul festgelegten Muster brechen. Und ich weiß, dass ich als Benutzer kaum mehr hasse, als mich mit Maven herumschlagen zu müssen, insbesondere die Abhängigkeiten meiner Abhängigkeiten ...

Ich sehe, dass stringtemplate ein @UseStringTemplateEngine obwohl @UseTemplateEngine vorhanden ist. Ist dies eine wünschenswerte Bequemlichkeitssache für jede Template-Engine oder bleiben wir ab jetzt lieber nur bei der generischen Annotation, wenn es nicht notwendig ist?

Persönlich hätte ich sie lieber in Module aufgeteilt, so dass Sie in Ihrer IDE nicht einmal eine Klasse sehen können, ohne dass ihre Abhängigkeiten transitiv in den Klassenpfad aufgenommen werden. NoClassDefFoundError kann ein echter Schmerz sein.

Ich habe in der Vergangenheit viel mit Freemarker gearbeitet. Es könnte ein lustiges Unterfangen sein, Unterstützung dafür zu implementieren. Es ist nicht direkt dafür gedacht. Aber es ist möglich. Auf die Leistung muss man gut achten.

Ich könnte eine Spitze daraus machen, wenn nichts anderes

arbeite gerade daran. Ich werde keinen Pull-Request öffnen, bevor ich einen vernünftigen Machbarkeitsnachweis habe. Bei der Verwendung von Configuration gibt es ein Problem, da das Laden von Vorlagen nicht statisch ist, sondern dynamisch sein muss. Daher muss jede Vorlage manuell geladen und zwischengespeichert werden. Ich habe das stringtemplate4-Modul geklont und die Klassen umbenannt usw. Wenn jemand interessiert ist, dann arbeite ich am Master-Zweig auf meinem jdbi-Fork.

Ich denke, die Situation, die zu diesem Problem geführt hat, ist eine Kombination aus den folgenden:

• StringTemplate 4 funktioniert im Allgemeinen außergewöhnlich gut (vorhersehbar, wenn nichts anderes) im Singlethread-Betrieb
• StringTemplate 4 wurde nicht mit besonderem Augenmerk auf die gleichzeitige Nutzung entwickelt, was zu Fehlern führte, die schwer zu beheben sind, ohne bestehende Benutzer zu beeinträchtigen, so dass sie meistens einfach so blieben, wie sie waren

Wenn ein StringTemplate 5 erstellt würde, würde ich erwarten, dass sichere Parallelität (und wahrscheinlich Unveränderlichkeit) eine große Rolle im Basisdesign spielt.