Comments 4
Мерзость. Рад за автора, что он решил прикольную computer science задачу и поднял свой скилл, но считаю итоговый продукт более вредным, чем полезным. Пусть SQL и имеет множество недостатков, но он
1) консистентен в своей парадигме. И планировщик и человек воспринимают запрос целостно, не делая избыточных декомпозиций. Когда на стороне юзера начинаются пайпы вида select(...).filter(...).join(...), то парадигмы разрываются. Человек видит императивный пошаговый алгоритм, когда планировщик видит декларативное описание. И, чтобы пользоваться таким, надо или быть говнокодером, которому пох на то, что делает база (будет медленно - пусть сервера новые покупают, не моя проблема), или раздваивать свою личность, одновременно написывая императивный код, и думая, как бд будет его выполнять.
2) Тупо знаком людям и ллмкам. Самописные orm приводят к тому, что профессионал с многолетним стажем обесценивает свой опыт, дотронувшись до нового проекта. Там, где вещи понятны as-is, он должен вчитываться и учить мануал. Тоже с LLM. Имея схему, они пишут SQL просто идеально, включая запросы на 200+ строк, работающие с первого раза.
3) Тут, возможно, я не вник, но проект напрочь игнорирует CTE. А это именно тот инструмент, который делает большие запросы понятными и доступными для прочтения в один проход
Спасибо за развёрнутую и честную критику. Но я не считаю CORMless «продуктом» в том смысле, который вы вкладываете. Это маленький инструмент для закрытия конкретной потребности, которую я заметил на практике.
Вы подсознательно сравниваете мою библиотеку с ORM или SQL — но это сравнение не совсем корректно. Вот моя логика:
Сравнение по пяти ключевым параметрам:
Объектный API (цепочки методов)
У Django ORM — ✅ есть
У чистого SQL — ❌ нет (это строки)
У CORMless — ✅ есть
Защита от SQL-инъекций
У Django ORM — ✅ есть (через параметризацию)
У чистого SQL — ❌ её нет по умолчанию, нужна строгая дисциплина разработчика (ручное экранирование или параметризация через курсор)
У CORMless — ✅ есть на уровне библиотеки (принудительная параметризация)
Кеширование с умной инвалидацией (по таблицам)
У Django ORM — ❌ нет из коробки, нужны костыли (сигналы, django-cacheops, ручное управление)
У чистого SQL — ❌ нет вообще, всё руками
У CORMless — ✅ есть из коробки (in-memory и Redis)
Поддержка моделей (маппинг таблиц на классы)
У Django ORM — ✅ есть
У чистого SQL — ❌ нет
У CORMless — ❌ нет, и это осознанное решение (работаем напрямую с таблицами)
CTE и сложные фичи SQL
У Django ORM — ✅ есть (через .raw() или .with_cte в новых версиях)
У чистого SQL — ✅ есть (вы пишете любой SQL)
У CORMless — ❌ пока нет (только через метод .query(raw_sql), но тогда теряется DSL)
Нужен инструмент, который делает запросы как ORM, но не требует моделей. Который ближе к SQL, но не настолько гибок, чтобы вы могли прострелить себе ногу. И который из коробки умеет кешировать с умной инвалидацией.
Про CTE вы правы — её нет. Потому что в моих сценариях (микросервисы-адаптеры, аналитика на лету, динамические схемы) она не понадобилась ни разу. Добавить CTE несложно, но это будет трата ресурса на функцию, которая не решает реальную боль. Я за минималистичные правки, которые делают своё дело, но не разрастаются в монстра.
Если появится реальный кейс с CTE в проекте без моделей — я добавлю. А пока:
Нужна ORM? Берите Django/SQLAlchemy.
Нужен полный контроль? Пишите сырой SQL.
Нужно быстро и с кешем, но модели избыточны? Вот CORMless.
Но главное, что я хочу сказать: я не предлагаю свою библиотеку как решение «для всех». Я закрываю ей свою боль. И делюсь этим опытом, своей мотивацией, идеями и подходами — не потому, что хочу, чтобы вы бежали ставить CORMless в прод. А потому, что хочу показать иной путь к решению.
Может быть, вы возьмёте из этого:
Идею инвалидации кеша по тегам таблиц.
Приём с двойным синхронным/асинхронным API без дублирования кода.
Или просто вдохновитесь написать свой велосипед, который идеально ляжет на вашу задачу.
В Open Source и IT-сообществе мне всегда казалось ценным не только «готовое решение», но и рассказ о том, как человек думал, ошибался, искал компромиссы. Это моя статья именно об этом. А библиотека на PyPI — просто приложение к этим мыслям.
Спасибо, что прочитали статью и написали свой комментарий.
Если у вас legacy-база или часто меняется структура БД, вы не можете заранее описать модели. Поддержка моделей превращается в бесконечную гонку.
Квк рвз в случае постоянной смены структуры БД ORM будет вас спасать от рассинхрона структуры в базе и в коде. Он всё-таки маппер.
Спасибо за вопрос — он действительно заставляет уточнить важную границу.
Вы абсолютно правы: ORM как маппер действительно спасает от рассинхрона, если вы можете поддерживать модели в актуальном состоянии. Но в моём сценарии — нет, не может.
Я не предлагаю CORMless как замену ORM. Я закрываю им свою боль. И делюсь опытом, а не призываю всех переходить на мою библиотеку.
В чём моя боль? Есть проекты, где:
Схема БД меняется быстрее, чем я пишу миграции (динамические tenant-таблицы, EAV, legacy без централизованных миграций).
Модели приходилось бы переписывать каждый день — это просто нереально.
Но при этом писать сырой SQL с ручной параметризацией и самодельным кешированием — утомительно и небезопасно.
В таких условиях ORM (даже крутой маппер) не спасает, потому что модель в коде и реальная таблица в БД расходятся за сутки. А CORMless при каждом запуске (или с TTL-кешем схемы) узнаёт актуальную структуру прямо из БД. Рассинхрон живёт не дольше, чем я разрешил.
Но ещё раз, главное: я не утверждаю, что мой подход лучше ORM. Я говорю: «Смотрите, есть и такой путь решения — для специфических случаев, где ORM избыточна или неприменима, а сырой SQL опасен и неудобен».
Моя цель — не убедить вас использовать CORMless. Моя цель — показать иной способ думать о задаче. А если кому-то это подойдёт — отлично. Если нет — значит, у вас нормальный проект с фиксированной схемой, и вам действительно лучше брать Django ORM или SQLAlchemy. И я искренне рад, что у вас нет моей боли:)
Спасибо, что прочитали и вдумались — такие комментарии помогают мне лучше формулировать, для чего этот инструмент не нужен, а это не менее важно, чем понимать, для чего он нужен.
Пишем свой SQL query builder на Python: DSL, кеширование в Redis и защита от инъекций