Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
В мире .net есть такая же либа: https://github.com/DapperLib/Dapper
А в truej можно привязывать параметры по именам, а не по позиции?
Спасибо за ваш вопрос. С целью упрощения API, в TrueSql нет именованных параметров. TrueSql старается не ставить перед разработчиками проблемы выбора. Даже самого минимального, что позволяет направить когнитивный ресурс на разработку, собственно, бизнес логики.
Понял. Просто с моей точки зрения - позиционные параметры вещь хрупкая и к багам ведущая. Но может у вас другой опыт. Я просто всегда на именованных параметрах сидел и хрупкость чисто умозрительно говорю.
Действительно, именованные параметры более устойчивы к изменениям. Это правда. Однако, мы всегда вынуждены выбирать исходя из некоторой суммы. Наименьший синтаксис и поддержка IDE из коробки(без каких либо сторонних плагинов) были важными метриками при разработке TrueSql - обычные вопросики (? - jdbc стандарт) они понимают лучше. Также в синтаксисе PG есть : и ::, значит такие синтаксические конструкцию пользователю пришлось бы экранировать.
Посмотрел чисто из любопытства. Возник единственный вопрос - опять же из любопытства.
Вы рассматриваете 5 различающихся по возвращаемому набору методов. Но все они получают ОДИН набор данных. В то же время некоторые СУБД вполне могут возвращать и несколько наборов, если в качестве выполняемого запроса используется обращение к хранимому объекту. Например, в MySQL хранимая процедура может вывалить в выходной поток несколько, а в теории в принципе сколько угодно, наборов данных. В том числе каждый из наборов вполне может иметь оригинальную, отличающуюся от других, структуру.
Может ли обрабатываться такой случай? Ведь в таком случае просто невозможно указать какой-то определённый результирующий класс..
Добрый день! Если кратко ответить на ваш вопрос, то ДА. Но есть нюансы, связанные с тем что время жизни курсоров - connection level, плюс не будет доступно проверок на этапе компиляции так как в JDBC метаданные курсоров untyped. Если вам нужен конкретный пример под вашу задачу, то вот контакты tg: @overln2, @aka_naked_gun
Вот признаться, совсем не понял, каким боком тут курсор. Он вообще тут вторичный исполнительный механизм.
Совсем по-обывательски ежели, то курсор - это такая штука, которую мы цепляем за набор записей, она в момент присоединения формирует структуру, которая соответствует структуре набора, и потом она ползёт по набору, получая оттуда записи, раскладывая их по полям структуры и отдавая это нам. То есть в момент, когда курсор находится где-то посередине полученного набора данных, мы не можем внести изменения в структуру, которая будет принимать записи из набора. То есть курсор - он не connection-level, он rowset-level, который в свою очередь connection-level. Просто это от нас прячут.
А я как раз говорю о случае, когда один результирующий набор, полученный нами, состоит не из записей, а из наборов с записями. То есть нужен какой-то над-метод, который за каждый отдельный набор записей будет цеплять свой курсор. Ну или один и тот же, но после того, как тот отфетчил предыдущий набор, с соотв. переинициализацией приёмной структуры. Особенно с учётом того, что подобные коллекции наборов записей на стороне SQL-сервера обычно forward-only.
Нет, даже обычный одиночный набор записей, полученный от простого запроса, на самом деле имеет такую же поли-структуру. Просто дефолтно ожидается единственный набор в коллекции, и курсор сразу цепляется за самый первый набор. Как я уже сказал, от нас это прячут.
Как раз ниже у вас в комментарии есть такие слова:
Драйвер привозит ResultSet, который является, структурно, плоской таблицей.
Так вот это как раз не обязательно. Драйвер запросто может привезти пачку таких плоских таблиц, различных по структуре.
Приветствую! Для работы с исключениями есть соответствующий 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, а пользователь сам разберётся сколько объектов он ожидает в ответ?
Действительно, fetchStream является наиболее общим интерфейсом, но дальше начинаются нюансы Java и ее stdlib.
FetchStream ленивый и держит внутри себя ResultSet и Connection, а в Java нет деструкторов, поэтому fetchStream можно использовать только через try-with-resource, иначе будут утечки
На Stream нет многих utility методов, которые есть, например, в Kotlin. Соответственно, разработчикам будет просто не удобно каждый раз писать один и тот же код: v = stream.findFirst(); if( v,isEmpty) throw ... и так далее
Если в джаве нет материализации стримов, то стоит её, наконец, изобрести.
А sql умеет возвращать беконечные наборы?
https://dlang.org/phobos/std_array.html#array
Это ничем не отличается от fetchList.
fetchStream можно использовать только через try-with-resource
При желании это всё решаемо простым flatMap()-ом.
Stream.of(fetchStream()).flatMap(Function.identity())
Читаю не первую статью о ваше библиотеке. Смотрели ли вы в сторону JOOQ https://www.jooq.org/? Ваше решение реализует такой же принцип работы с базой, но при этом в JOOQ очень хорошо реализована типобезопасность параметров запросов, да и при сборке запроса также осуществляется его валидация на этапе компиляции. Чем ваше решение лучше?
Добрый день! Вы видимо считаете что JOOQ хорошая технология, однако подумайте о том что JOOQ существует более 16 лет и при этом имеет <<1% market-share. TrueSql не стоит денег. Ваш вопрос про валидацию: в TrueSql всё это есть и даже лучше, следите за будущими публикациями. Тезисно ответил чем TrueSql лучше JOOQ в нашем тг-канале: https://t.me/TrueSql.
Прочитал ваши тезисы, жаль, что вы не изложили их здесь. Пока из ответов явных преимуществ не увидел. Как реализуется валидация средствами БД? Отправкой некорректного запроса и получением ошибки?
<<1% market share
6300 звёзд, 1200 форков
Для сравнения у спринга 57500 звёзд, а у trueSql - 14.
У кого нет своего мозга, тот думает чужим.
Это вы что имеете ввиду? Поясните, пожалуйста.
Ну раз вы так просите, то подумаю за вас: вы меряетесь звёздами, форками и маркет шарами, надеясь, что все те миллионы мух провели технический анализ и выбрали лучшее решение из возможных, а на самом деле большая часть из них не то что технического, а вообще никакого анализа не сделала и порой даже не пробовала в деле.
Вы меня извините, но я отвечал на конкретный тезис про "<<1% market share". Что, очевидно, не правда - и количество звёзд в репозитории здесь отличный показатель.
Ещё меня несколько напрягает токсичность евангелистов этой вашей чудо-библиотеки: вместо того, чтобы ответить по существу, они зачем-то сравнивают незнакомых людей с мухами и делают необоснованные выводы о чужих умственных способностях. Не надо так!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
TrueSql – заново учимся ходить в базу данных. Часть 1 – пять Fetch’ей