Jdbi: Отказать от поддержки StringTemplate4 и отказаться от нее

Начнем с заметки в документации о том, что проект StringTemplate неактивен.

Я позволю другим участникам проекта взвесить вопрос об отказе от интеграции Jdbi с ST. Лично я считаю, что мы должны поддерживать его хоть какое-то время. Мы только начали поддерживать ST4.

Думаю, нам нужна альтернатива. Нет возможности создавать сложные шаблоны для sql. Мне нужно иметь возможность обмениваться битами и частями sql между разными шаблонами и иметь возможность выделять общие вещи в методы шаблонов. Для меня удаление шаблона строки заставляет меня искать другую альтернативную структуру. В противном случае я был бы вынужден создавать файлы sql с большим количеством дубликатов.

Давайте сейчас добавим NOTICE . Мы можем отказаться от него, как только у нас будет жизнеспособная замена.

Есть ли у кого-нибудь любимые движки шаблонов, которые хорошо вписались бы в jdbi? Я немного использовал mustache и все было хорошо, но я далек от эксперта ...

Спасибо @jarlah , я этого и ожидал.

К сожалению, StringTemplate игнорируется в апстриме, но пока люди его используют и он работает, у нас нет причин отказываться от поддержки.

Мы очень довольны FreeMarker, где я работаю. Усы тоже хороший вариант.

Согласитесь с @jarlah - нужна альтернатива. Я также активно использую шаблоны, и без ST будет массовое дублирование. Альтернатива должна быть простой и выразительной - что мне нравится в нынешнем СТ. Я использовал Freemarker очень давно, и, если я правильно помню, для создания шаблонов SQL это выглядит непросто.

Кстати, вот моя последняя проблема с ST, я могу опубликовать ее здесь с кодом обхода на уровне интеграции jdbi?

Если есть простой обходной путь, который jdbi может обойтись без особого усложнения, мы обязательно его рассмотрим.

Каким образом дополнительные templateEngines будут включены в jdbi? Все они вносят внешние зависимости, которые нам не нужны в core , и не создают модуль 1-класса и не устанавливают \

Тем не менее, у IIRC stringtemplate есть собственный модуль mvn, так что, может быть, нам просто нужно продолжать это делать? В любом случае это звучит как меньшая хлопотливость для пользователей, чем дополнительные зависимости.

Мне было бы интересно внести свой вклад в движок StringSubstitutor (если я еще не сделал этого), и Mustache тоже кажется довольно интересным.

Если это автономный одиночный класс с единственной зависимостью <optional> или аналогичный легкий, он может входить в ядро. В противном случае давайте раскрутим модуль. Мое предпочтение должно было быть ориентиром, а не непреодолимой планкой :)

Однако это нарушит шаблон, установленный модулем stringtemplate4. И как пользователь я знаю, что ненавижу больше, чем возиться с maven, особенно с зависимостями моих зависимостей ...

Я вижу, что шаблон строки получил @UseStringTemplateEngine несмотря на то, что @UseTemplateEngine существует. Является ли это желательным удобством для каждого механизма шаблонов или мы лучше просто будем придерживаться общей аннотации только с этого момента, если в этом нет необходимости?

Лично я бы предпочел разделить их на модули, чтобы вы даже не могли видеть класс в своей среде IDE без его зависимостей, транзитивно включенных в путь к классам. NoClassDefFoundError может быть настоящей болью.

В прошлом я много работал с freemarker. Было бы забавно реализовать его поддержку. Это напрямую не предназначено для этого. Но это возможно. Придется хорошенько взглянуть на производительность.

Я мог бы сделать это, если бы ничего другого

в настоящее время работаю над этим. Я не собираюсь открывать пул-реквест, пока у меня не будет разумного рабочего доказательства концепции. При использовании конфигурации возникает проблема, поскольку загрузка шаблона не статическая, она должна быть динамической. Поэтому каждый шаблон необходимо загружать и кэшировать вручную. Я клонировал модуль stringtemplate4 и переименовал классы и т. Д. Если кому-то интересно, то я работаю над основной веткой на моей вилке jdbi.

Я думаю, что ситуация, которая привела к этой проблеме, представляет собой комбинацию следующего:

• StringTemplate 4 обычно работает исключительно хорошо (предсказуемо, если ничего другого) в однопоточном использовании.
• StringTemplate 4 не был разработан с особым акцентом на одновременное использование, что привело к ошибкам, которые трудно исправить, не нарушая работу существующих пользователей, поэтому они в основном просто оставались такими, какими были.

Если бы был создан StringTemplate 5, я бы ожидал, что безопасный параллелизм (и, вероятно, неизменяемость) будет играть большую роль в базовом дизайне.