SQLAlchemy: а ведь раньше я презирал ORM

Люди не роботы и ищут примерно одинаково. Никто не ищет автомобили по весу, а ноутбуки по материалу корпуса (ищут, но можно пренебречь). Равно как и запросы с десятком параметров

Нотация О-большое для самых маленьких

2) Сколько времени уходит на материализацию запроса, а сколько съедается на транспорте к БД? Мы оптимизируем 5% от общего времени запроса?
3) Секунда на результат в UI — это нормально. Если запрос в БД через ORM обрабатывается в пределах 500мс, то оптимизация — это пустая трата времени. Но мой опыт с EF.Core говорит, что 20-30мс достижимо.

О, ещё один любитель мерять производительность секундомером. Я рассказывал, как можно не вычислять вообще. Вам приходило в голову, что сэкономленное время CPU может быть израсходовано на другой запрос?

Я тут пол статьи рассказывал, что самый страшный затык по производительности — это затык в БД, как важно выжимать из SQL-запроса всё, что можно, рассказывал про SQL-хинты (бывает, БД некорректно оценивает cardinality, что приводит к трэшовому плану запроса). Говорил о том, что приложение можно масштабировать, а БД нельзя.

И что? Мне предлагают другую ORM. На другом языке. Уровень, который можно отмасштабировать.

Блин, если бы хоть слово было сказано про возможности генерации SQL в EF. Так нет же, только про скорость исполнения и секундомер.

Да, я подразумеваю кэширование строки запроса. Сборка запроса достаточно дорогая. При этом строка запроса переиспользуется в хвост и в гриву.

Кэширование же результата запроса абсурдно. Я много раз в статье говорил об инвалидации кэша, и кэширование результатов запроса лишь усугубляет эту проблему.

Я не говорю о том, что кэши не нужны. Я говорю о том, что кэши нужно применять, задействуя верхний мозг.

Кроме собственно строки обычно кэшируется подготовленный запрос (prepared statement). Сборка строки может быть сравнительно недорогой, но вот prepare — может быть очень дорого, для этого и нужен кэш запросов.

Как по-вашему вообще возможно написать такой запрос который имеет сразу все условия фильтрации

def where_clause_iter(self, params: frozenset):
    has_price_min = 'price_min' in params
    has_price_max = 'price_max' in params
    has_price_between = has_price_min and has_price_max

    if has_price_between:
        yield Product.price.between(
            bindparam('price_min', required=True),
            bindparam('price_max', required=True),
        )
    elif has_price_min:
        yield Product.price >= bindparam('price_min', required=True)
    elif has_price_max:
        yield Product.price >= bindparam('price_max', required=True)

    if 'color' in params:
        yield Product.color == bindparam('color', required=True)

    if 'vendors' in params:
        yield Product.vendor.in_(bindparam('vendors', required=True))

    ...

def where_clause(self, params: frozenset):
    where_clause_gen = self.where_clause_iter(params)
    where_clause = next(where_clause_gen)

    for next_clause in where_clause_gen:
        where_clause &= next_clause

    return where_clause

Вроде, изячно. То же самое с сортировками, группировками и прочим

Если я правильно вас понял, речь идёт о том чтобы в запросе иметь нечто вроде:

SELECT * FROM table
WHERE (:parm1 IS NULL OR (col1 = :parm1))
AND (:parm2 IS NULL OR (col2 = :parm2))

Выглядит конечно заманчиво, но есть нюанс (о котором я говорил раньше) — нет абсолютно никаких гарантий что сначала будет проверено условие "IS NULL" для параметра, т.е. сервер может впустую сравнивать все параметры (которые не указаны) с данными из таблицы. Да, в идеале оптимизатор должен это прочухать — но всё же гарантий нет.

И ещё момент — кроме условия "=" может быть "<>" — а вот это в один запрос впихнуть уже проблематично. Можно конечно как-то так:

SELECT * FROM table
WHERE (:parm1eq IS NOT NULL AND (col1 = :parm1eq))
OR (:parm2ne IS NOT NULL AND (col2 <> :parm2ne))

и вынести выбор параметров в приложение (передавая только один в зависимости от условия), но проблема с неопределенным порядком остается, да и в отличие от большинства "нормальных" ЯП в SQL нет "короткого замыкания" в логических операторах, плюс есть шанс что планировщик сойдёт с ума и план для "универсального" запроса может быть значительно дороже чем для узкоспециализированного.

Собственно, в сложных системах где запросы ещё могут использовать другие операторы (типа LIKE или BETWEEN) всё уже просто становится неподъёмно и сильно усложняет код — так что динамическая генерация самый простой способ, а в сочетании с кэшем и учётом того что вариантов (реально используемых) всё же не очень много это отлично работает.

Потому, что эти метаданные ручками из подзапроса выгрести не получится. Без интроспекции вам придётся или всё теми же ручками расписывать, как работать с каждой колонкой

На PHP в Yii будет как-то так.

Product::find()->where($filter)
  ->with('productCategory')
  ->with('productCategory.category')
  ->all();

SELECT * FROM product WHERE (:filter) LIMIT :offset, :pageSize;
SELECT category_id FROM product_category WHERE product_id IN (:productIdList);
SELECT * FROM category WHERE id IN (:categoryIdList);

4 строки, 3 простых запроса. К вопросу о кешировании результата, результат третего запроса неплохо кешируется, так как категории редко меняются.
Можно через JOIN сделать, но тогда пагинацию и общее количество надо будет по-особому обрабатывать. Если фронтенд кеширует категории у себя, второй with делать не надо.
В ответе сервера просто появится новое поле, фронтенд-фреймворки вроде нормально справляются с такими ситуациями.

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

И тут влетаете вы и утверждаете, что я предлагаю усложнить код.

Я вас не понимаю. Я тут показываю: смотрите, алхимию легко плагинить! Смотрите, удобные макросы! А ещё тело макросов можно будет подменить — DIP же! Смотрите, как просто использовать свои типы! И всё это позволяет выжать максимум производительности! И код получается предельно простым!

То ли лыжи не едут, то ли я еб***тый

Я тоже делал свой набор провайдеров. Я не знаю, как это предлагали делать у вас — я исходил из того, что каждый эндпоинт — это отдельный класс (ибо каждый эндпоинт имеет какую-то собственную причину для существования). Код снаружи его инстанцирует, передаёт туда необходимый минимум данных и нажимает единственную кнопку "Пыщь!" — ибо LSP. Внутри код идентичен коду в моей статье — предельно простой конечный автомат с элементарными стадиями. Сам же код эндпоинта — это комбинация миксинов зачастую без единой строки кода — "всё уже написано до вас".

Более того, я сторонник "толстого common", и при малейших намёках на реюзаемость компонента тащу его в common. Это вовсе не значит, что я вообще весь код храню там. Это значит ровно то, что я написал: я активно реюзаю свой код. И, следуя OCP, я крайне редко (но это бывает) вношу в этот код изменения, чтобы какой-то частный случай заработал — всё это я делаю в классе-наследнике. И нет, мой код от этих изменений не ломался никогда: зачастую я всего лишь выделяю из метода какой-то блок и выношу его в другой метод, ибо сразу соблюсти SRP не всегда удаётся.

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

Возможно, мы живём в разных вселенных.

Проблема не в задержке ирндексации а в том что рано или поздно из-за проблем в работе реального сетевого приложения данные рассогласовываются в основной базе и в поисковом индексе. И его приходится принудительно обновлять перечитыванием от начала и до конца. Действительно для магазина среднего это такое малое количество данных что можно этим перенбречь. Но не всегда задачи имеют малый объем. Например один из индексов у меня проходит проверку раз в сутки потому что перебор всех значений занимает 4 часа. И это к сожалению реальная проблема синхронизации. И несколько раз в год бывает негативная обратная связь от клиента что в индексе устаревшие данные.

то есть реально вставляется вопросик, позиционная переменная или процентик — в зависимости от того над чем пишется темплейт

А, тогда всё гуд

ошибочная пара SELECT-списка и GROUP-списка. Такое только MySQL позволяет, в силу своей кривизны.
Другие базы дадут ошибку на данный запрос.

Я же говорил, что я этот запрос никогда не исполнял) У меня нет таких сущностей даже близко. Я на скорую руку менял запрос

ошибочная пара SELECT-списка и GROUP-списка. Такое только MySQL позволяет, в силу своей кривизны.

Увы, не только MySQL — ещё SQLite.

Интересно. А что послужило причиной отказа от alembic?

Да, там не всё гладко. Но в скрипте миграции я первым делом вкидываю в переменные окружения ALEMBIC=1

В некоторых местах я смотрю на наличие этой переменной. В частности, для alembic нужен синхронный драйвер БД, в том время как приложения использует асинхронный. Connection URI я собираю в специальном классе, где много смотрю в переменные окружения

Ещё нюанс с собственными типами возник. Приходится городить огород:

if 'ALEMBIC' in environ:
    MyColor = Integer
    MyIntEnum = Integer
else:
    MyColor = ColorType
    MyIntEnum = IntEnumType

Меня это не устраивает. Ещё придумаю чего. Есть мысль в __new__ залезть