Если никто не пишет нормальную библиотеку – надо написать её первым. (С) Владимир Торвальдс
Напомним, что TrueSql это новая Java-библиотека для работы с базами данных под лицензией Apache 2.0. Конфигурация, как и любая другая часть TrueSql, сделана правильно. Сегодня мы расскажем про то как настроить TrueSql на вашем новом (или старом добром) проекте. В статье вы узнаете о том как делать правильно и как делают неправильно неправильные разработчики библиотек.
pure Java, baby
Для конфигурации TrueSql понадобятся: одна Java-программа, открытость ума к правильным решениям и одна книжка по Spring Data JPA чтобы не забыть ее выбросить как только дочитаете эту статью. Итак, этап компиляции в TrueSql позволяет:
не запуская программу, проверить корректность SQL-запросов и соответствие количества и типов переданных аргументов
реализовать кодогенерацию мапперов и DTØ, следовательно получить максимальную производительность и минимальный boilerplate
гарантировать отсутствие SQL-инъекций
Чтобы настроить TrueSql нужно сделать два простых шага:
1. Создать класс, наследующий DataSourceW или ConnectionW.
public class PgDs extends DataSourceW {
public PgDs(DataSource w) { super(w); }
}Изначально мы не хотели заворачивать java.sql.DataSource в свои структуры чтобы сделать TrueSql ультра-тонкой надстройкой над JDBC. Однако, в какой-то момент стало понятно что нужно дать возможность оперировать сразу несколькими базами данных с разной схемой в рамках одного Java-модуля. В итоге, для различения баз данных появились DataSourceW и ConnectionW. ConnectionW нужен если вы хотите встроить TrueSql в ту часть кодовой базы, где вам доступно уже только соединение, а не ConnectionPool (например, плагины чего-нибудь).
2. Указать параметры подключения к базе данных на которой будут проходить проверки этапа компиляции. Этот шаг опционален, но крайне рекомендуем.
@Configuration(
checks = @CompileTimeChecks(
url = "jdbc:postgresql://localhost:5432/test_db",
username = "user",
password = "userpassword"
)
) public class PgDs extends DataSourceW {
public PgDs(DataSource w) { super(w); }
}Очевидно, что нужна возможность поменять эти значения в зависимости от рабочей среды, например на CI/CD. Для этого процессор аннотаций TrueSql использует переменные окружения. Названия этих переменных формируются исходя из имени класса из пункта 1. Для получения имен и применённых значений используйте флаг к системе сборки, пример на gradle:
./gradlew build -Dtruesql.printConfig=true
gradlew>
truesql.xxx.PgDs.url=jdbc:postgresql://localhost:5432/test_db
truesql.xxx.PgDs.username=user
truesql.xxx.PgDs.password UNDEFINEDmaven вариант
./mvnw clean install -Dtruesql.printConfig=trueМы даже сделали так, что вы можете отличить “null” значение параметра от незаданного. В этом случае вы увидите UNDEFINED без знака =. Встанем и выпьем за те прекрасные времена, когда каждая UNIX-программа имела флаг -h.
У вас могли возникнуть следующие вопросы:
Вопрос 1: Как я буду работать с git, если у нас свои локальные тестовые базы с разными параметрами подключения?
Ответ: Сделайте одинаковые параметры подключения к локальным тестовым базам данных. (тривиально)
Вопрос 2: Но я пришел на проект, где порядка никогда не было и у нас общая тестовая база или я вообще тестирую на проде – у нас стартап. Закоммитить креды в git я не могу.
Ответ: Используйте переменные окружения. Способов много: прописать их в gradle.properties (jvm.config если maven), IDE, shell, bashrc и так далее. Рекомендуется сделать это в gradle.properties, пример:
systemProp.truesql.xxx.PgDs.url=jdbc:postgresql://localhost:5432/truesqldb
systemProp.truesql.xxx.PgDs.username=user
systemProp.truesql.xxx.PgDs.password=userpasswordПример для maven .mvn/jvm.config:
-Dtruesql.xxx.PgDs.url=jdbc:postgresql://localhost:5432/truesqldb
-Dtruesql.xxx.PgDs.username=user
-Dtruesql.xxx.PgDs.password=userpasswordТеперь вы можете убрать параметры подключения из аннотации @CompileTimeChecks.
Вопрос 3: Как мне добавить вторую базу данных в проект?
Ответ: Для второй БД повторить пункты 1 и 2, описанные выше. (тривиально)
Резюме: все настройки TrueSql проводятся в аннотации @Configuration и в классе, реализующем DataSourceW (ConnectionW). TrueSql автоматически, через переменные окружения, даёт вам возможность переопределить настройки зависящие от рабочей среды. Посмотреть примененные значения вы можете через флаг -Dtruesql.printConfig=true.
“Никто не пишет библиотеки так хорошо как это делаю я” (С) Дональд Трамп
Вспомните трудности при конфигурации других библиотек. В TrueSql этого нет. TrueSql отличная библиотека и сегодня мы доказали это в контексте конфигурации:
Вся конфигурация пишется на Java, вам не нужно знать дополнительные языки вроде XML, YAML.
Есть только один способ что-то настроить! Это освобождает вас от проблемы выбора. Приходя на проект с TrueSql вы сразу знаете куда смотреть. Можете сравнить это с %Spring Data%.
Композиция. TrueSql не перехватывает управление (IoC) и не создает дополнительных абстракций потому что "это круто". Например, в jdbi придумали какие-то Handle... А в Spring есть микрочудовище LocalContainerEntityManagerFactoryBean, один из сотен кстати.
Вы имеете 100% code-completion даже в community-idea или vscode. Значит вам не надо искать возможные ключи в интернете (вы же про yaml конфигурации подумали).
Главный кабан двора
Что делать с полученной властью? Держать любой ценой!
Создатели Spring придумали гениальную схему как сделать Spring незаменимым:
spring.datasource.todos.hikari.connectionTimeout=30000
spring.datasource.todos.hikari.idleTimeout=600000
spring.datasource.todos.hikari.maxLifetime=1800000HikariCP находится в заложниках пока разработчики Spring не добавят поддержку конкретно этих ключей. Данный подход полностью уничтожает любую композицию, но зато делает Spring незаменимым! При попытке найти другой способ сконфигурировать HikariCP в Spring мы открыли 3 первых ссылки на Baeldung, а там то же самое!
TrueSql это не просто Java-библиотека – это источник здравого смысла на Java-платформе. Мы продолжим борьбу за здравый смысл в следующих статьях!
