А тебе jooq чем-то (кроме стека) не подходит или не видел его раньше?

Ну или точнее так - есть ли у SQLi принципиальные отличия от jooq ?

Тут 3 момента:

- Не слышал про jooq
- Он вроде только под Java, SQLi сейчас под Go, но я буду его расширять (надо просто дописать теймплейты для других языков)
- У него классическая дот нотация (select().from()...), я использую функциональную нотацию (query(select(), from(), ...), что (1) намного ближе к SQL, (2) результат любой функции это объект { sql: string, args: any[] }, а значит можно самому писать функции / такие структуры и использовать их внутри (то есть, не надо лезть в библиотеку и расширять методы объектов, чтобы что-то работало)

Тут 3 момента:

- Не слышал про jooq
- Он вроде только под Java, SQLi сейчас под Go, но я буду его расширять (надо просто дописать теймплейты для других языков)
- У него классическая дот нотация (select().from()...), я использую функциональную нотацию (query(select(), from(), ...), что (1) намного ближе к SQL, (2) результат любой функции это объект { sql: string, args: any[] }, а значит можно самому писать функции / такие структуры и использовать их внутри, то есть, если тебе нужна какая-то кастомизация, не надо лезть в библиотеку и расширять методы объектов, (3) мы не ограничены конкретной БД, то есть, даже если нет интроспекции на какую-то БД, сами типы можно написать вручную, а SQLi будет спокойно работать с любым SQL синтаксисом

ок, понял, спасибо

Как пример кастомизации: у нашей кастомной базы есть оператор MERGE table WHERE ... COLLISION ..., которая сливает несколько записей вместе, в SQLi функции merge и collision нет, но мы можем сделать так:

function merge(tableName: string) {
return {
sql: `MERGE ${tableName}`,
}
}

function collision(type: "free" | "restricted") {
return {
sql: `COLLISION $`,
args: [type]
}
}


И использовать так:

query(merge(tableName), where(...), collision("free"))

То есть, даже не надо комитить что-то в SQLi чтобы добавить новые операторы

А в чем отличие от SQLc?

SQLc берет чистый SQL выражение и генерирует из него код

Это отлично подходит для сложных статических SQL (я сам его использовал)

НО если нужно собрать динамический SQL (добавлять / удалять операторы в зависимости от входящих условий, например, собрать сложную строку поиска с самого дешевого ресурса поика авиабилетов Авиасэйлс), то сделать это на SQLc ооочень сложно

Придется писать нативные SQL CASE WHERE, который крайне тяжело контролировать

Поэтому если есть задача писать очень типобезопасные но статические SQL, то лучше использовать SQLc, а SQLi использовать в паре с ним для динамических запросов

А в чем типобезопасость такого решения?

По мне сейчас так лучше писать запросы в sql, а дальше уже из sql файлов сгенерировать интерфейс и не писать запросы в коде вообще тогда. Это куда лучше по DX выходит, когда язык не способен что-то выразительнее чем sql предложить (а это оч сложно)

Вот пример https://github.com/giacomocavalieri/squirrel/tree/main и sqlc(?) в го

А ну еще в SQLi есть автоматическая генерация всех видов INSERT / UPDATE / DELETE, что в SQLc придется каждый раз писать самому

А в чем сложность контролировать case where?

Их же сейчас ИИ пишет, травишь агенту свою базу локально, он тебе хоть миллион скуэля скучного напишет

Каждая функция проверяет коректность названий и типов аргументов

В дальнейшем можно будет добавить также проверку сочетаемости разных функций, но сейчас нет на это времени

Для кого-то писать большие CASE WHERE будет норм, тут можно привести выигрывающий аргумент, НО CASE WHERE просто не способен сделать взаимоисключающие или взаимодополняющие аргументы

И во всех моих последних проектах 5 лет я все время с такими сталкивался и уходил от SQLc на query builder (в которых не было других фишек SQLi)

Мои попытки просить написать SQL запросы через нейронки только разочаровывали меня: до сих пор они дико путаются в фактологии и пишут или нерабочий или неоптимальный код

Только мы зайдем на территорию json в PG и они начинают галлюцинировать

НО если есть классное проверенное решение, буду рад совету

я стараюсь давать агентам как можно больше контекста (нужно настроить семантический граф нейронки на нужные мне темки) и доступа, если хочется большего использую MCP, ищу их тут https://smithery.ai/

но для базовых INSERT / UPDATE / DELETE достаточно дать хороший промпт и прописать правильно rules для курсора (написать где лежат миграции, в каком стиле должны быть операции). и потом оно просто хавает это дело и все. с json в PG (если у вас много таких запросов) можно им дать валидатор с уровня кода, показать правильный пример, направить читать доку 😄

Ооо кайф, посмотрю)