А есть ли ЯП, которые умеют обходиться без системы сборки?

Жутко неудобно, конечно

А в чём конкретно неудобство?

Во-первых ORM может быть не привязана к SQL

Допусти, только что мешает при этом юзать SQL для описания?

а если привязана, то такая ORM не нужна

Бред же.

Который отличается от СУБД к СУБД

Тот же Hibernate, если не ошибаюсь, имеет усреднённый DML, ничто не мешает сделать также для DDL.

что мешает при этом юзать SQL для описания

Например то, что он будет невалидным для конкретной СУБД. Ты хочешь чтобы ORM полностью разбирал SQL и транслировал SQL<->SQL? Нафига он тогда вообще нужен, сразу СУБД и используй. Вообще SQL это язык команд/запросов, а не описания данных.

так это единственно правильный вариант при чтении БД, в ней id - пользователь ушёл покурить на час, если ты сразу же вытащишь все данные по этому id, то когда юзер вернётся, они могут стать тупо неактуальными

Вопрос не в валидации. Добрая часть вытаскиваемых данных может быть не нужна. Запросы идут в контексте связанной с этими данными объектами, а еще часто получается минимум один запрос к бд из таблицы с параметрами на каждый объект, к которому они привязаны. Куча объектов, куча запросов, куча оверхеда. И в итоге всё заканчивается какими-нибудь hql запросами, костылями, dto и такой-то матерью, что намного проще делать без orm.

Тарифы с периодами актуальности, параметры с периодами актуальности

И что? ORM обычно идёт в паре с билдером запросов, т.е. можно соорудить что угодно, что возможно для конкретной СУБД (ну или почти).

И что? ORM обычно идёт в паре с билдером запросов, т.е. можно соорудить что угодно, что возможно для конкретной СУБД (ну или почти).

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

Если дошло до запросов руками

Во-первых это не запросы руками, а запросы средствами ORM. А во-вторых запросы никак не связаны с ORM, суть которой в том, чтобы заворачивать сырые данные в объекты, которые ценны сами по себе, а не в контексте хранения данных, т.к. реализуют алгоритмы работы с этими данными в приложении. А уж откуда берутся эти данные - дело десятое, хоть sql фигачь по-старинке. Да, во многих ORM есть средства, для ускорения этого процесса, в т.ч. можно указать зависимые таблицы, чтобы джойнить или лениво вытаскивать релейшены, но это не отменяет возможности дополнительного отбора в т.ч. уточнения автоматически генерируемых запросов (вместо их полного написания).

Так вот, ORM есть смысл тащить не из-за запросов, а из-за того, что с данными нужно как-то работать, помимо просто выплёвывания в html/json. В 90% случаев в вебе ORM не нужно, достаточно какого-нибудь билдера запросов (ибо крутить SQL на коленке всё-таки не очень удобно).

всё равно пишешь запросы руками в sql,

не руками а средствами orm типа

>>> total_price_of_shopping_carts = select([
...     ShoppingCart.id.label('shopping_cart_id'),
...     func.sum(Product.price).label('product_price_sum')
... ]).where(
...     and_(
...         ShoppingCartProductLink.product_id == Product.id,
...         ShoppingCartProductLink.shopping_cart_id == ShoppingCart.id,
...     )
... ).group_by(ShoppingCart.id)

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

выбрать актуальные параметры по 10 тарифам или выбрать какую-то их часть.

это все делается средствами orm, вообще любые запросы делаются.

Во-первых это не запросы руками, а запросы средствами ORM

А зачем? Вот ORM выдаёт по дефолту херню вместо запросом. Надо неделю с ней сношаться, чтобы она что-то выдала. А когда дба скажет, что там что-то база разрослась и мы тут кое что сейчас поменяем - еще 2 недели. И в чём профит? В том, что бы в начале разработки сделали херак-херак и в продакшен? Или что у нас есть т.н. СУБД независимость? Да это полная херня. Вы каждую неделю меняете субд что-ли?

объекты, которые ценны сами по себе

Ценны до того, как начинаются пляски с ДТО. А они начинаются всегда, когда дело выходит за рамки бложека из 3 таблиц.

реализуют алгоритмы работы с этими данными в приложении

Нихрена на них не реализуешь ничего сложнее бложека. Хотя бы потому, что в контексте объекта получится много мелких запросов.

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

Да да. Выходишь за границы связей один-много, много-много и садишься в лужу на месяц.

Хотя бы потому, что в контексте объекта получится много мелких запросов

Ещё раз, специально для тебя, запросы, их качество и количество не имеют отношения к ORM вообще, а только к кривизне рук. ORM нужна не для того чтобы делать запросы, а чтобы делать объекты. Можно натянуть ORM на сырые SQL запросы в т.ч.

В том что тебе надо описывать схему где-то отдельно, вместо того, чтобы описать ее самим классом или вытянуть из бд. В том что генерированный код перезатрется после изменений, ты не можешь там же описать какие-то методы, свойства и кастомное поведение. В общем после чего-то типа алхимии к такому не захочется возвращаться. Да даже после django orm.

В том что тебе надо описывать схему где-то отдельно, вместо того, чтобы описать ее самим классом или вытянуть из бд

Если ты про доктрину, то можно и так и так. В туториале все примеры с аннотациями прямо в классах entity.

генерированный код перезатрется после изменений

4.2

Если у тебя в проекте один запрос, но, конечно проще написать его руками и орм не нужна. Но как правила там их много и, основном, простые, которые на нее легко ложатся. Кроме того, есть сущности, с которыми гораздо удобней работать через orm. Например если хранишь древовидные данные в субд.

не руками а средствами orm типа

Да это не особо важно. Конструкторов запросов хватает и в не-orm, чтобы ей перечислять поля, таблицы, связи условия а оно всё это еще и мапило. К orm это уже не имеет отношения, потому что тупо мапинг результата какого-то запроса в какую-то струкутру, когда orm предполагает именно пляску от самих этих структур, с созданием запросов вокруг них.
Запрос выглядит как говно, кстати. Даже на sql это было бы лучше.

это все делается средствами orm, вообще любые запросы делаются.

Любые запросы делаются и без orm. Так зачем оно? Чтобы преодолевать не нужные трудности с его постижением?

ORM нужна не для того чтобы делать запросы, а чтобы делать объекты.

А чтобы хоть что-то работало, а не создавало ИБД нужны хорошие запросы.

Можно натянуть ORM на сырые SQL запросы в т.ч.

Можно. Но зачем? Чтобы просто замапить объект целый ORM не нужен.

целый ORM не нужен

Целый не нужен, нужен минимальный. Тебя кто-то заставляет жрать автогенерацию запросов? Не обязательно нажимать все кнопки, которые есть на пульте управления.

Если у тебя в проекте один запрос, но, конечно проще написать его руками и орм не нужна. Но как правила там их много и, основном, простые, которые на нее легко ложатся.

Это справедливо для бложека. Для всего что больше - нет. Сложные системы, сложные запросы и просадка по бд.

Например если хранишь древовидные данные в субд.

Хочешь расскажу, что будет после этого «удобно». Сначала выяснится, что orm делает по одному запросу на объект. Потом ты полезешь что-то с этим делать, выяснять какой массив тебе нужен и запрашивать его куском. А потом еще и выкидывать не нужные данные, которые привяжутся к объектам на которые ссылаются элементы этого дерева и потомкам этих объектов. А потом ты изобретешь ДТО и sql/полуsql запросы из твоего orm. И у тебя будет по ДТО на каждую задачу. А потом ты вспомнишь этот тред.

Я это последний раз трогал лет 13 назад, когда еще php был актуален и приходилось на нем писать. Но недавно бегло смотрел изменилось ли что, все выглядит все так же убого, но это из-за ограничений самого php, где нет ни метаклассов, ни дескрипторов(лол http://xdissent.com/2010/01/15/mimicking-python-descriptors-in-php/) ни всяких __eq__. Но можно конечно привыкнуть и терпеть, особенно, если ничего лучше не видел.

А зачем нужен целый тракторный завод ради одного токаря, чтобы он выточил переходник?

Сфигали, смысл как раз в том, что эффективные способы хранения деревьев и запросам к ним выглядят просто жутко на sql, а orm сильно облегчает с ними работу.

делает по одному запросу на объект

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

всего что больше - нет.

Все что больше надо поддерживать большой командой, развивать, мигрировать и т.п. С лапшой из sql это нереально тяжело.

сложные запросы

Кстати никто не мешает из класть в какие-нибудь materialized views

Сфигали, смысл как раз в том, что эффективные способы хранения деревьев и запросам к ним выглядят просто жутко на sql, а orm сильно облегчает с ними работу.

Не жудко. С ними невозможно работать на sql, нужен какой-то яп. Вопрос как затащить всё это в яп. И тут мы говорим про orm. Но работать с полученными данными - это не orm.

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

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

Все что больше надо поддерживать большой командой, развивать, мигрировать и т.п. С лапшой из sql это нереально тяжело.

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

Кстати никто не мешает из класть в какие-нибудь materialized views

Не мешает. А еще можно сделать таблицу в ram и туда делать insert-update. Только это нахер не нужно в 9 из 10 случаев.

ORM нужна не для того чтобы делать запросы, а чтобы делать объекты. Можно натянуть ORM на сырые SQL запросы в т.ч.

Ты либо троллишь, либо не понимаешь сути ORM. Это маппинг отношений на классы, после которого ты работаешь в рамках отображенной модели данных. Натягивать ORM на запросы — полнейший провал, когда уже абстракция не подтекает, а хлещет струей. Так как нормально отобразить реляционную модель в объектную трудно (если вообще возможно), то хлещет оно у ормофанов перманенто.

perl да и практически любой старый скриптовый язык.

Это маппинг отношений на классы

Да, и кто сказал, что отношения должны быть заданы только через fk, а не произвольным запросом?

ради одного токаря, чтобы он выточил переходник

Ради одного не нужен. Это не значит, что он не нужен вообще.

А почему у тебя объекты не могут формироваться запросом. Например

subq = select([
            func.count(orders.c.id).label('order_count'),
            func.max(orders.c.price).label('highest_order'),
            orders.c.customer_id
            ]).group_by(orders.c.customer_id).alias()

customer_select = select([customers, subq]).\
            select_from(
                join(customers, subq,
                        customers.c.id == subq.c.customer_id)
            ).alias()

class Customer(Base):
    __table__ = customer_select

это из-за ограничений самого php

Плохому танцору... ну ты понял.

ORM зачем нужен то? Чтобы абстрагироваться от SQL. А ты предлагаешь и объектную модель описывать, и запросы ручками писать и привязывать к модели? Эпичная протечка, как я уже говорил. Можно просто сырые результаты перепаковывать в структуры ЯП, но это не ORM.

Ну написал ты запрос не прямо на SQL, а через прокладку. Что это меняет? Кроме того, что теперь труднее стало его оптимизировать сторонним спецам.

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

Аналогично с другими вещами, например, запрос к эластику это может быть простыня из сонет строк json, но с помощью elasticsearch-dsl ее можно довольно элегантно генерить.

На самом деле, ORM в языках без нормального ООП и перегрузки операторов — вещь почти бестолковая. Ибо красивый лаконичный SQL превращается в жуткую лапшу из вызовов, а профиты при этом сомнительные. Если пробовал SQLAlchemy, то на всякие суррогаты ORM уже не поведёшься.

А потом руководство решит мигрировать с питона на мудон, и вот тут ты попал со своей алхимией.

Например то, что он будет невалидным для конкретной СУБД

Для того, чтобы стал валидным и нужен ORM.

Ты хочешь чтобы ORM полностью разбирал SQL и транслировал SQL<->SQL? Тот же Hibernate, если не ошибаюсь, имеет усреднённый DML

Это не я придумал, погугли HQL.

Нафига он тогда вообще нужен

Ну да, а описание на XML всё резко меняет.

Ровно так же как попал бы, если бы писал на любом другом языке и любом другом ORM. Так к чему ты это?

ORM зачем нужен то? Чтобы абстрагироваться от SQL

Абстрагироваться не значит выкинуть, а значит завернуть в абстракцию. Нужен для того чтобы получать на выходе готовые объекты, а не массив данных. Ваш, К.О.

запросы ручками писать и привязывать к модели

Если нужно, да. Как получаются запросы - дело десятое, суть не в этом. То что ORM обычно автогенерируют запросы для простых случаев, это конечно замечательно, но не является признаком ORM как таковой.

описание на XML всё резко меняет

Да, потому что это декларативное описание.

погугли HQL

А ты его используешь чтобы описывать схему БД? Вместо аннотаций, как делают все нормальные люди?

потому что это декларативное описание

А DDL какое? Императивное чтоли, лол.

А ты его используешь

Я не пишу на жабке.

Императивное чтоли, лол

Да, бывает, в т.ч. SQL. Внезапно, лол?

Я не пишу на жабке

Зачем тогда об этом рассуждать? То на что ты изначально ответил, было лютое 4.2 и не соответствует действительности, ибо в доктрине как раз 1:1 как в жабке. Описание на xml/yaml/<что угодно в одном файле> возможно и оно имеет свои плюсы.

К тому, что орм не нужен.

Ну тогда от обратного. Решит руководство поменять мускуль на постгре, вот тут ты и обделаешься. А алхимия мне почти всё зарешает.

Да, бывает, в т.ч. SQL. Внезапно, лол?

DDL на создание таблиц. Упоролся?

Зачем тогда об этом рассуждать?

HQL был как раз в тему трансляции из SQL в SQL.

Неплохо, тогда оно точно подходит.

Может и может. Хз. Но это абсолютный быдлокод.

Спорно. Многие ORM так делают. Впрочем, меня больше интересует именно сама теоретическая возможность, как возможные пределы кодогенерации. Это же не только для ORM надо, другая типичная задача - генерация GUI классов, в зависимости от xml конфига, ну как любая формошлёпная либа умеет, будь то Qt, .NET, gtk или delphi

Поэтому внутри может быть что угодно.

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

Ну так ui файлы не зависят от внешнего мира. Они статичные. С базой так не выйдет.

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

Без понятия.

Ну так ui файлы не зависят от внешнего мира. Они статичные. С базой так не выйдет.

ЯННП, в каком месте БД во время сборки не статичная?

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

А почему у тебя объекты не могут формироваться запросом. Например

Могут. То, что тянется по ссылкам на эти объекты - тоже может. И можно еще формировать запросы на вставку, чтобы когда ты 10к раз сделаешь set не получилось 10к запросов. Но при чём тут orm?

Нужен для того чтобы получать на выходе готовые объекты

Ты получаешь не просто готовые объекты, а объекты, которые синхронизируются с бд. Маппить массив в объекты ормом это оверкилл.

Решит руководство поменять мускуль на постгре, вот тут ты и обделаешься. А алхимия мне почти всё зарешает.

Охлол, нет. Придет постгреспец и за день все запросы перепишет. Что ты будешь делать с тысячами запросов на алхимии, густо замешанных с логикой, я не знаю даже. Вешаться?