Ребята, у меня тут с коллегой небольшая дискуссия. У

нас небольшое разногласие в плане синтаксиса query builder'а.
Какой вообще кому синтаксис больше по душе и почему?

QB("table")
.where("col1", "=", 1)
.whereColumn("col1", "=", "col2")
.whereIn("col1", [1, 2, 3])
.whereNotIn("col1", [1, 2, 3])
.whereBetween("col1", [1, 10])
.whereNotBetween("col1", [1, 10])
.whereExists(QB())
.whereNotExists(QB());

Второй вариант:
QB("table")
.where`col1 = ${1}`
.where`col1 = col2`
.where`col1 in ${[1, 2, 3]}`
.where`col1 !in ${[1, 2, 3]}`
.where`col1 between ${[1, 10]}`
.where`col1 !between ${[1, 10]}`
.where`exists ${QB()}`
.where`!exists ${QB()}`;

Первый. Потому что скобки. Во втором они есть и далее нету..

А зачем тебе скобки?

консистентность. Шучу. Ну что за вопросы.. В первом явно используем методы, а во втором это что?..

Ну это тегированный метод. Впервые слышишь что-ли? Да ну!

😞

тогда вопрос: во втором варианте есть возможность передать аргументами список методов? Как?

Туда можно передать всё что угодно!

В первом понятно: QB( "table" )[ method ]( ... ), а во втором как это проделать в рамках JS?

А зачем так делать вообще? Никогда (очень редко) так не делай!

есть автотесты и их генерация 💁‍♂️ Будешь везде вручную всё прописывать? Я и спрашиваю, как во втором варианте можно автоматизировать процесс (не только тестов, а вообще).

Ну если ты хочешь написать именно так, то что тебе мешает в цикле прогнать всё? Ведь название метода одинаковое у всех. Это в первом варианте разные методы

В том-то и дело, что в первом варианте я могу получить список методов и прогнать всё необходимое в тестах. Во втором варианте мне уже надо гонять условия.

Вообще не аргумент!

😟

Тогда даже не знаю, что на это ответить. Используйте, что считаете удобным в вашем случае.

Просто, скорее всего, тебе сложно представить всю картину, но я попробую пояснить! Дело в том, что помимо методов where* будут ещё другие и если ещё учитывать вариант orWhere, то методов условий будет слишком много и они просто засрут весь автокомплит. Но самая проблема ещё начала крыться в другом. Есть другой метод, называется having и проблема в том, что для него нужно сделать все (почти все) те же варианты типа: havingIn, havingNotIn и т.д. и тогда вообще хаос.

А ты гарантируешь, что при прямой подстановке через ${val} там не будет инъекции? Выглядит так себе

Да, гарантирую!

Конечно засрут И в твоём варианте тоже засрут Надо писать raw sql

Я пока что тебе не верю

Значит ты просто не в курсе как работает tagged functions

Ну ты знаешь, половина людей кричат, что билдеры фуфло, а другая половина кричит, что DSL лучше. Я выбрал между двумя золами.

Я правильно понимаю, что во втором варианте ни о какой инкапсуляции raw sql кода речи не идет?

Идёт!

Есть класс, предоставляющий данные методы (любые, публичные), которые мы можем получить нативными средствами JS (не мне тебе рассказывать как). Я в цикле могу прогнать всё необходимое для собственных нужд передав лишь массив необходимых мне методов (собственно - получили массив методов, передали на выполнение). having не having - вообще по боку. Суть в том, что я могу написать один (!) тест, в котором буду проверять корректность всех методов по условию, вместо написания по одному тесту на это условие для каждого (!) метода. А если их стопятьсот? Предлагаешь столько же тестов писать? А завтра поменяем что-нибудь - переписывать? Ещё и тесты править? Опять?.. О _ о Вот я и спрашиваю, есть ли во втором варианте возможность динамического построения логики выполнения? Я не спорю, мне интересно.