Jdbi: Desencorajar e descontinuar o suporte StringTemplate4

Vamos começar com um aviso na documentação de que o projeto StringTemplate está inativo.

Vou deixar os outros membros do projeto opinarem sobre a questão de descontinuar a integração ST do Jdbi. Pessoalmente, acho que devemos continuar apoiando por pelo menos um pouco de tempo. Nós apenas começamos a oferecer suporte ao ST4.

Acho que precisamos de uma alternativa. Não ter uma maneira de criar modelos complexos para sql é inútil. Eu preciso ser capaz de compartilhar sql bits e partes entre diferentes modelos e ser capaz de fatorar coisas comuns em métodos de modelo. Para mim, remover stringtemplate está me fazendo procurar outra estrutura alternativa. Do contrário, seria forçado a criar arquivos sql com muita duplicação.

Vamos adicionar NOTICE agora. Podemos descontinuá-lo assim que tivermos um substituto viável.

Alguém tem motores de modelagem favoritos que se encaixam perfeitamente no jdbi? Usei mustache um pouco e funcionou bem, mas estou longe de ser um especialista ...

Obrigado @jarlah , era mais ou menos o que eu esperava.

É uma pena que o StringTemplate esteja sendo negligenciado pelo upstream, mas, desde que as pessoas o estejam usando e funcione, não há razão para retirarmos o suporte.

Estamos muito felizes com o FreeMarker onde trabalho. O bigode também é uma boa opção.

Concorde com @jarlah - uma alternativa é necessária. Também estou usando modelos ativamente e a duplicação será massiva sem o ST. A alternativa deve ser simples e expressiva - o que eu gosto na ST atual. Usei o Freemarker há muito tempo e, se bem me lembro - não parece simples para modelos SQL.

BTW Aqui está meu último problema com ST. Devo publicá-lo aqui com o código de solução alternativa no nível de integração jdbi?

Se houver uma solução simples que jdbi pode fazer sem complicar muito as coisas, certamente a consideraríamos.

Como o templateEngines adicional seria empacotado no jdbi? Todos eles trazem dependências externas que não queremos em core , e nem criar um módulo de 1 classe nem definir um \

O stringtemplate do IIRC tem seu próprio módulo mvn, então talvez devêssemos continuar fazendo isso? De qualquer forma, parece menos incômodo de hacky para os usuários do que dependências opcionais.

Eu estaria interessado em contribuir com um mecanismo StringSubstitutor (se ainda não o fiz), e o Mustache também parece muito divertido de fazer.

Se for uma classe única independente com uma única dependência <optional> , ou similarmente leve, ela pode ir no núcleo. Caso contrário, vamos girar um módulo. Minha preferência era para ser uma diretriz, não um obstáculo impossível de ser aprovado :)

Porém, isso quebraria o padrão definido pelo módulo stringtemplate4. E sei que, como usuário, há pouco mais que odeio do que ter que mexer com o maven, especialmente as dependências de minhas dependências ...

Vejo que o stringtemplate obteve um @UseStringTemplateEngine apesar de existir @UseTemplateEngine . Esta é uma conveniência desejável para cada mecanismo de template ou preferimos apenas ficar com a anotação genérica apenas a partir de agora, a menos que seja necessário?

Pessoalmente, eu preferiria que eles fossem divididos em módulos, de modo que você não possa nem ver uma classe em seu IDE sem suas dependências incluídas transitivamente no caminho de classe. NoClassDefFoundError pode ser uma verdadeira dor.

Eu trabalhei muito com o freemarker no passado. Implementar suporte para ele pode ser divertido. Não foi feito diretamente para isso. Mas é possível. Tenho que dar uma boa olhada no desempenho.

Eu poderia fazer um pico se nada mais

atualmente trabalhando nisso. Não vou abrir uma solicitação pull antes de ter uma prova de conceito funcional razoável. Há um problema com o uso da Configuração, porque o carregamento do modelo não é estático, deve ser dinâmico. Portanto, cada modelo deve ser carregado e armazenado em cache manualmente. Clonei o módulo stringtemplate4 e renomeei as classes, etc. Se alguém estiver interessado, estou trabalhando no branch master no meu fork do jdbi.

Acho que a situação que levou a esse problema é uma combinação do seguinte:

• StringTemplate 4 geralmente funciona excepcionalmente bem (previsível, se nada mais) no uso de thread único
• StringTemplate 4 não foi projetado com ênfase particular no uso simultâneo, o que levou a bugs que são difíceis de resolver sem quebrar os usuários existentes, então eles permaneceram como estavam

Se um StringTemplate 5 fosse criado, eu esperaria que a simultaneidade segura (e provavelmente a imutabilidade) desempenhasse um grande papel no design básico.