Jdbi: Desalentar y desaprobar el soporte de StringTemplate4

Comencemos con un aviso en los documentos de que el proyecto StringTemplate está inactivo.

Dejaré que los otros miembros del proyecto opinen sobre la cuestión de desaprobar la integración ST de Jdbi. Personalmente, creo que deberíamos seguir apoyándolo al menos durante un tiempo. Recién comenzamos a admitir ST4 en primer lugar.

Creo que necesitamos una alternativa. No tener una forma de crear plantillas complejas para sql es imposible. Necesito poder compartir partes y bits sql entre diferentes plantillas, y poder factorizar cosas comunes en métodos de plantilla. Para mí, eliminar stringtemplate me hace buscar otro marco alternativo. Si no, me vería obligado a crear archivos sql con mucha duplicación.

Agreguemos un NOTICE ahora. Podemos desaprobarlo una vez que tengamos un reemplazo viable.

¿Alguien tiene motores de plantillas favoritos que encajarían bien en jdbi? He usado mustache un poco y estuvo bien, pero estoy lejos de ser un experto ...

Gracias @jarlah , eso era lo que esperaba.

Es lamentable que StringTemplate se esté descuidando en sentido ascendente, pero mientras la gente lo use y funcione, no hay razón para que retiremos el soporte.

Estamos muy contentos con FreeMarker donde trabajo. El bigote también es una buena opción.

De acuerdo con @jarlah , se necesita una alternativa. También estoy usando activamente plantillas y la duplicación será masiva sin ST. La alternativa debe ser simple y expresiva, lo que me gusta del ST actual. Usé Freemarker hace mucho tiempo y, si lo recuerdo correctamente, no parece simple para las plantillas SQL.

Por cierto, aquí está mi último problema con ST, ¿debo publicarlo aquí con un código de solución en el nivel de integración de jdbi?

Si hay una solución alternativa simple que jdbi puede hacer sin complicar demasiado las cosas, sin duda la consideraríamos.

¿Cómo se agruparían los templateEngines adicionales en jdbi? Todos traen dependencias externas que no queremos en core , y no hacen un módulo de 1 clase ni configuran un \

Sin embargo, IIRC stringtemplate tiene su propio módulo mvn, así que tal vez deberíamos seguir haciendo eso. De todos modos, suena menos complicado para los usuarios que las dependencias opcionales.

Me interesaría contribuir con un motor StringSubstitutor (si aún no lo he hecho), y Moustache también parece bastante divertido de hacer.

Si es una clase única autónoma con una única dependencia <optional> , o similarmente liviana, puede ir en el núcleo. De lo contrario, hagamos girar un módulo. Mi preferencia estaba destinada a ser una guía, no una barrera imposible de pasar :)

Sin embargo, eso rompería con el patrón establecido por el módulo stringtemplate4. Y sé que como usuario hay poco más que odio que tener que meterme con maven, especialmente las dependencias de mis dependencias ...

Veo que la plantilla de cadena tiene un @UseStringTemplateEngine pesar de que @UseTemplateEngine existe. ¿Es esto una conveniencia deseable para todos los motores de plantillas o preferimos ceñirnos a la anotación genérica solo de ahora en adelante a menos que sea necesario?

Personalmente, preferiría dividirlos en módulos, de modo que ni siquiera pueda ver una clase en su IDE sin sus dependencias incluidas transitivamente en la ruta de clases. NoClassDefFoundError puede ser un verdadero dolor de cabeza.

He trabajado mucho con freemarker en el pasado. Podría ser un desafío divertido implementar soporte para él. No está destinado directamente a ello. Pero es posible. Hay que analizar bien el rendimiento.

Podría hacer un pico de eso si nada más

actualmente trabajando en ello. No voy a abrir una solicitud de extracción antes de tener una prueba de concepto razonable. Hay un problema con el uso de la configuración, porque la carga de la plantilla no es estática, debe ser dinámica. Por tanto, cada plantilla debe cargarse y almacenarse en caché manualmente. Cloné el módulo stringtemplate4 y renombré las clases, etc. Si alguien está interesado, estoy trabajando en la rama maestra en mi bifurcación de jdbi.

Creo que la situación que condujo a este problema es una combinación de lo siguiente:

• StringTemplate 4 generalmente funciona excepcionalmente bien (predecible si nada más) en el uso de un solo subproceso
• StringTemplate 4 no se diseñó con un énfasis particular en el uso concurrente, lo que provocó errores que son difíciles de resolver sin dañar a los usuarios existentes, por lo que en su mayoría simplemente se quedaron como estaban.

Si se creara una StringTemplate 5, esperaría que la concurrencia segura (y probablemente la inmutabilidad) desempeñara un papel importante en el diseño base.