Как проверить все SQL запросы разом?

Тесты и есть от безрукости, безмозглости и криворукости. А люди на длинных дистанциях все такие.

Какой кошмар. Вас всех надо уволить.

Я же всё починил очень давно. При доброй воле главного инженера и содействии коллег, конечно. Технари были виноваты только в попустительстве, а основаная вина была на некомпетентном руководстве.

Тот же тимвьюер был не от хорошей жизни, а из-за отсутствия vpn до сервачков. Это решалось организационно, технари ничего поделать не могли. Впрочем, когда осознали, что так жить нельзя, ситуация быстро изменилась.

Ты бы знал как стремительно росла культура разработки и требования к рабочим процессам и решениям. Через пару лет я уже сам переиодически фалломорфировал от этих требований. Например, буквально вчера автоматических бекапов во внутренней инфраструктуре вообще не было, а сегодня уже нельзя самому скрипты нафигачить, нужно обязательно взять бакулу.

И почему ты на меня-то гонишь? Я же выше написал, что так было, когда я туда пришел. Когда я оттуда ушел, всё было уже совсем иначе.

Я подумал что ты этот зверинец и развёл.

пилил генератор отчётов,

клиент в наличии

Шаблоны и запросы писались и поставлялись отдельно от программы.

голыми update/insert, я так понимаю?

почему не всегда применимо. Если не придумаешь, дам пример из личной практики

ну и где он? в чём проблема-то была?

клиент в наличии

Нет никакого клиента. Точнее клиент есть, но он сообщает серверу только идентификатор запроса в хранилище.

голыми update/insert

Сорян, но ты тупой? Отчёты. Только селекты.

Проблема в том, что ты дико тупишь.

он сообщает серверу только идентификатор запроса в хранилище

Поправка — идентификатор шаблона, а иднетификаторы запросов вшиты в шаблон.

Проблема в том, что ты дико тупишь.

туплю я, а не осилили ORM в такой простой архитектуре вы

Нет никакого клиента. Точнее клиент есть, но он сообщает серверу только идентификатор запроса в хранилище.

тогда это ультрапростая архитектура, да у меня не хватает фантазии представить, как тут за счёт ORM можно накосячить

Сорян, но ты тупой? Отчёты. Только селекты.

как будто селект не может вести к update/insert через вызываемую процедуру или триггер

а, вы в БД совсем, что-ли, не умеете? тогда вопросов более не имею

Ты упёртый и отбитый. Запросы к софтине не имеют никакого отношения, они кастомные, пишутся под каждый отдельный отчёт (шаблон). Что не ясно?

как будто селект не может

Не может, если у юзера прав нет. Дуй в школу, неуч.

Запросы к софтине не имеют никакого отношения, они кастомные

отлично. вы обещали рассказать, чем ORM может помешать, в вашем примере этого не видно

Не может, если у юзера прав нет.

this

Видно, просто некто — шланг.

Ещё раз, запросы поставляются отдельно от софта. Программист не пишет отчёты, запросы к ним тоже, в этом весь прикол.

Откуда им взяться? Не шлангуй. Админ может и под рутом доступ по ssh открыть.

ORM не единственный паттерн для работы с базой, не стоит так сильно зацикливаться.

Программист не пишет отчёты, запросы к ним тоже, в этом весь прикол.

это отвечает на вопрос «в каких случаях ОРМ излишня»

это не отвечает на вопрос «как при помощи ОРМ выстрелить себе в ногу», который я задал

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

Не всегда применимо и не всегда нужно

всегда применимо, всегда удобнее, но не серебряная пуля

попробуй всё же маленько подумать почему не всегда применимо. Если не придумаешь, дам пример из личной практики

давайте свой пример

Не вижу где ты такой вопрос задал, но да ладно. Предлагаю сойтись на том, что мы друг друга не поняли.

Отчётер сам по себе stateless. Как я уже сказал, источник данных может быть любой. БД — лишь один из них.

источник данных может быть любой. БД — лишь один из них

ок, если из БД через какого-либо посредника возвращается, грубо говоря, pdf, то тут никакого ORM не надо, но тут и работы с базой c клиента не идёт

но чтобы этот pdf сгенерировать, надо всё-таки, эти данные базы чем-то вытянуть, вот в этом «чем-то» как раз и удобно использовать ORM, чтобы правильно типизировать результат выполнения запросов и дальше уже рисовать красивые графики

при этом, всегда найдётся достаточно простой случай, когда ORM будет излишне, или наоборот, достаточно сложный (типа, когда куча таблиц может создаваться юзером) и ОРМ будет неприменимо

ок, я немного не так понял, что вы имеете в виду под словом «применимо»

в общем, теперь я вас понял, вы были правы

ORM не единственный паттерн для работы с базой

Mustache шаблоны!

# cat get_client_by.mustache.sql

SELECT id, reg_time, phone, name
FROM clients
WHERE {{column}} = $1;

Статические гарантии правда так себе:) Зато переносимость 100%, т.к. этот шаблонизатор есть под все ЯП

WHERE {{column}} = $1;

https://www.youtube.com/watch?v=P2_sjEURwgo&t=3736

На что это ты намекаешь?

https://en.wikipedia.org/wiki/SQL_injection

Я же не предлагаю строить запросы на основе пользовательских данных. Есть независимый от хранилища слой, предоставляющий функции getClientByPhone, getClientById (вместо него многие используют ORM, что по-моему не совсем правильно). Рендеринг шаблонов внутри этого слоя исключительно на контролируемых разработчиком значениях. А пользовательские данные передаются штатными средствами драйвера через $1. (Тут, кстати, Postgres сосет, т.к не умеет в именованные параметры)

function getClientByPhone(phone: string): Client | null {
  const res = db.query(
    Mustache.render(GET_CLIENT_BY, { column: 'phone' }),
    [phone]
  );
  return res.rows[0] || null;
}

Можно включать/отключать части запроса, передавать списки столбцов, менять условия. В общем, параметризировать непараметризируемое :)

Я же не предлагаю строить запросы на основе пользовательских данных. Есть независимый от хранилища слой, предоставляющий функции getClientByPhone, getClientById (вместо него многие используют ORM, что по-моему не совсем правильно). Рендеринг шаблонов внутри этого слоя исключительно на контролируемых разработчиком значениях. А пользовательские данные передаются штатными средствами драйвера через $1. (Тут, кстати, Postgres сосет, т.к не умеет в именованные параметры)

Я в своём ОРМ не парю мозг независимыми от хранилиза слоями, потому что ОРМ сам является этим слоём. Ещё я не парю мозг о контроле значений и пользовательских данных, потому что ОРМ их сам фильтрует. И именованые параметры в драйвере конкретной БД меня не заботят, потому что ОРМ это абстрагирует.

Ну ок, шаблоны тоже прокатят.

Ещё я не парю мозг о контроле.. пользовательских данных, потому что ОРМ их сам фильтрует

Ты про такое? Нашел в манах по AlchemySQL:

mytable = Table('mytable', meta,
    Column('col1', Integer, CheckConstraint('col1>5')),
    Column('col2', Integer),
    Column('col3', Integer),
    CheckConstraint('col2 > col3 + 5', name='check1')
    )

Это ж придется входные данные загружать прямиком в модель. Ну не знаю.. Они ж могут и не соответствовать модели, может требоваться преобразование. Один фиг придется где-то отдельно предварительно провалидировать