Добрый день! Вы видимо считаете что JOOQ хорошая технология, однако подумайте о том что JOOQ существует более 16 лет и при этом имеет <<1% market-share. TrueSql не стоит денег. Ваш вопрос про валидацию: в TrueSql всё это есть и даже лучше, следите за будущими публикациями. Тезисно ответил чем TrueSql лучше JOOQ в нашем тг-канале: https://t.me/TrueSql.
Думаю в наших рассуждениях нет противоречий. Комментарий про плоскую структуру я дал в контексте одного выходного result set. Позже пришлем пример двух result set для mysql.
Приветствую! Для работы с исключениями есть соответствующий API. Наличие/отсутствие в БД констрейнта с нужным именем также проверяется на этапе компиляции. Если вам нужно вернуть поля из удаленной строки, то воспользуйтесь .asGeneratedKeys() в TrueSql или returning в PG и, соответствующим fetch (уже не fetchNone). Если нужно количество "затронутых" строк, в TrueSql есть .withUpdateCount. Подробное описание этого функционала будет дано в следующих статьях.
По поводу плотности WTF мы вас не поняли, вы можете смотреть на выходные колонки в запросе или сгенерированные DTO. Также, эти сгенерированные DTO автоматически появятся и в open API (см. комментарий выше).
В TrueSql нет проблемы N+1, аналогичной ORM-библиотекам, TrueSql вообще не ORM-библиотека. TrueSql исполняет запрос на стороне базы данных. Драйвер привозит ResultSet, который является, структурно, плоской таблицей. Из неё собирается одна/несколько DTO. Собираются они через дополнительный group-by на Java стороне в случае, если в dto появляются не только скаляры, но и списки.
Действительно, fetchStream является наиболее общим интерфейсом, но дальше начинаются нюансы Java и ее stdlib.
FetchStream ленивый и держит внутри себя ResultSet и Connection, а в Java нет деструкторов, поэтому fetchStream можно использовать только через try-with-resource, иначе будут утечки
На Stream нет многих utility методов, которые есть, например, в Kotlin. Соответственно, разработчикам будет просто не удобно каждый раз писать один и тот же код: v = stream.findFirst(); if( v,isEmpty) throw ... и так далее
Добрый день! Если кратко ответить на ваш вопрос, то ДА. Но есть нюансы, связанные с тем что время жизни курсоров - connection level, плюс не будет доступно проверок на этапе компиляции так как в JDBC метаданные курсоров untyped. Если вам нужен конкретный пример под вашу задачу, то вот контакты tg: @overln2, @aka_naked_gun
Действительно, именованные параметры более устойчивы к изменениям. Это правда. Однако, мы всегда вынуждены выбирать исходя из некоторой суммы. Наименьший синтаксис и поддержка IDE из коробки(без каких либо сторонних плагинов) были важными метриками при разработке TrueSql - обычные вопросики (? - jdbc стандарт) они понимают лучше. Также в синтаксисе PG есть : и ::, значит такие синтаксические конструкцию пользователю пришлось бы экранировать.
Спасибо за ваш вопрос. С целью упрощения API, в TrueSql нет именованных параметров. TrueSql старается не ставить перед разработчиками проблемы выбора. Даже самого минимального, что позволяет направить когнитивный ресурс на разработку, собственно, бизнес логики.
Добрый день! Динамический SQL это обширная тема и в рамках дизайна TrueSql разумеется мы об этом думали. В скором времени запланирована статья с разбором всех кейсов динамического SQL и ответами в рамках TrueSql. Если вас не затруднит, пришлите пример такого динамического SQL, который вам нужен: tg @overln2, @aka_naked_gun.
Если вам долго писать, предлагаю созвониться в телеграмме и вы объясните что имеете ввиду, а мы подумаем и ответим сразу или письменно сформулируем, контакт для связи @aka_naked_gun
Спасибо за предложение, и за то что ознакомились с проектом. Пока пароли от maven central храним на отдельной машине. По поводу версий Java, то основная версия это 21+. Во многом, потому что было самим очень удобно реализовать TrueSql на свежей джаве. Бэкпорты на 17 и ниже стоят в планах, но тут ждем запроса от вендоров
Да, так и есть, однако если посмотреть на market share этих технологий, то мы увидим тотальное доминирование ORM. Значит, на это есть причины. И, как нам кажется, причины в деталях реализации. Кстати, можете рассказать что на практике значит "при необходимости с помощью рефакторинга превращается в именованный тип" ? Как выглядит такой рефакторинг?
В предложенной концепции, схема декларируется в SQL скриптах миграции. Все запросы пишутся "по месту", то есть с базы получаются нужные проекции в виде dto. Сами dto это рекорды или классы с final полями - никаких аннотаций на них нет. Поля dto инферятся автоматически, исходя из запросов. Все решение 100% typesafe
Да, эти решения можно отнести к другой категории. Тем не менее, они тоже предоставляют очень большой API, и не реализуют концепций, указанных в третьем разделе настоящей статьи. Что, их и приводит к довольно малой рыночной нише
Лучшее решение для работы с БД это TrueSql, имхо, можно тут в видос с аргументами посмотреть: https://t.me/TrueSql/53
Это всё конечно хорошо, но как же TrueSql? И не надо было бы сову на глобус натягивать…
Добрый день! Вы видимо считаете что JOOQ хорошая технология, однако подумайте о том что JOOQ существует более 16 лет и при этом имеет <<1% market-share. TrueSql не стоит денег. Ваш вопрос про валидацию: в TrueSql всё это есть и даже лучше, следите за будущими публикациями. Тезисно ответил чем TrueSql лучше JOOQ в нашем тг-канале: https://t.me/TrueSql.
Думаю в наших рассуждениях нет противоречий. Комментарий про плоскую структуру я дал в контексте одного выходного result set. Позже пришлем пример двух result set для mysql.
Приветствую! Для работы с исключениями есть соответствующий API. Наличие/отсутствие в БД констрейнта с нужным именем также проверяется на этапе компиляции. Если вам нужно вернуть поля из удаленной строки, то воспользуйтесь .asGeneratedKeys() в TrueSql или returning в PG и, соответствующим fetch (уже не fetchNone). Если нужно количество "затронутых" строк, в TrueSql есть .withUpdateCount. Подробное описание этого функционала будет дано в следующих статьях.
По поводу
плотности WTF
мы вас не поняли, вы можете смотреть на выходные колонки в запросе или сгенерированные DTO. Также, эти сгенерированные DTO автоматически появятся и в open API (см. комментарий выше).В TrueSql нет проблемы N+1, аналогичной ORM-библиотекам, TrueSql вообще не ORM-библиотека. TrueSql исполняет запрос на стороне базы данных. Драйвер привозит ResultSet, который является, структурно, плоской таблицей. Из неё собирается одна/несколько DTO. Собираются они через дополнительный group-by на Java стороне в случае, если в dto появляются не только скаляры, но и списки.
Действительно, fetchStream является наиболее общим интерфейсом, но дальше начинаются нюансы Java и ее stdlib.
FetchStream ленивый и держит внутри себя ResultSet и Connection, а в Java нет деструкторов, поэтому fetchStream можно использовать только через try-with-resource, иначе будут утечки
На Stream нет многих utility методов, которые есть, например, в Kotlin. Соответственно, разработчикам будет просто не удобно каждый раз писать один и тот же код: v = stream.findFirst(); if( v,isEmpty) throw ... и так далее
Добрый день! Если кратко ответить на ваш вопрос, то ДА. Но есть нюансы, связанные с тем что время жизни курсоров - connection level, плюс не будет доступно проверок на этапе компиляции так как в JDBC метаданные курсоров untyped. Если вам нужен конкретный пример под вашу задачу, то вот контакты tg: @overln2, @aka_naked_gun
Действительно, именованные параметры более устойчивы к изменениям. Это правда. Однако, мы всегда вынуждены выбирать исходя из некоторой суммы. Наименьший синтаксис и поддержка IDE из коробки(без каких либо сторонних плагинов) были важными метриками при разработке TrueSql - обычные вопросики (? - jdbc стандарт) они понимают лучше. Также в синтаксисе PG есть : и ::, значит такие синтаксические конструкцию пользователю пришлось бы экранировать.
Спасибо за ваш вопрос. С целью упрощения API, в TrueSql нет именованных параметров. TrueSql старается не ставить перед разработчиками проблемы выбора. Даже самого минимального, что позволяет направить когнитивный ресурс на разработку, собственно, бизнес логики.
Добрый день! Динамический SQL это обширная тема и в рамках дизайна TrueSql разумеется мы об этом думали. В скором времени запланирована статья с разбором всех кейсов динамического SQL и ответами в рамках TrueSql. Если вас не затруднит, пришлите пример такого динамического SQL, который вам нужен: tg @overln2, @aka_naked_gun.
Приветствую!
Если вам долго писать, предлагаю созвониться в телеграмме и вы объясните что имеете ввиду, а мы подумаем и ответим сразу или письменно сформулируем, контакт для связи @aka_naked_gun
Приветствую!
Во время проектирования TrueSql, jdbi тоже изучался. Из принципиальных вещей там нет:
Проверок запросов на этапе компиляции
Генерации выходных dto
Древовидных выборок, которые полностью меняют ситуацию с отчетами и rest-контроллерами
И много чего там еще нет или сделано неправильно
Приветствую!
record User(long id, String name) {}
ds.q("select id, name from users").fetchList(User.class)
Шаг 1. TrueSql, в классе dto (User) ожидает конструктор с ненулевым количество параметров. Если его нет, или их несколько - ошибка компиляции
Шаг 2. Генерирует маппер вида
new User(rs.getLong(1), rs.getString(2))
Шаг 3. Если включена проверка запросов, то проверяется соответствие выходных колонок запроса сигнатуре конструктора (количество параметров, типы)
А в режиме генерации dto:
ds.q("select id, name from users").g.fetchList(User.class)
TrueSql сам создаст класс User. Имена полей получит путем преобразования имен выходных колонок из snake_case в camelCase
Спасибо за предложение, и за то что ознакомились с проектом. Пока пароли от maven central храним на отдельной машине. По поводу версий Java, то основная версия это 21+. Во многом, потому что было самим очень удобно реализовать TrueSql на свежей джаве. Бэкпорты на 17 и ниже стоят в планах, но тут ждем запроса от вендоров
Да, так и есть, однако если посмотреть на market share этих технологий, то мы увидим тотальное доминирование ORM. Значит, на это есть причины. И, как нам кажется, причины в деталях реализации. Кстати, можете рассказать что на практике значит "при необходимости с помощью рефакторинга превращается в именованный тип" ? Как выглядит такой рефакторинг?
В предложенной концепции, схема декларируется в SQL скриптах миграции. Все запросы пишутся "по месту", то есть с базы получаются нужные проекции в виде dto. Сами dto это рекорды или классы с final полями - никаких аннотаций на них нет. Поля dto инферятся автоматически, исходя из запросов. Все решение 100% typesafe
Здравствуйте, args это аргументы query. Среди них класса "сущности", поэтому нет
Да, эти решения можно отнести к другой категории. Тем не менее, они тоже предоставляют очень большой API, и не реализуют концепций, указанных в третьем разделе настоящей статьи. Что, их и приводит к довольно малой рыночной нише
SpringData это тоже ORM
Здравствуйте, ActiveRecord это ORM-подход.
В статье предлагается не-ORM подход и, цитата,
поэтому, нет