Пыхотред

средний пыхоплеядник вообще не понимает

причем тут пыхоплеяда?

90% программистов вообще тупые упёртые утята как pawnhearts.

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

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

когда я слышу кеширование или ORM я сразу на этом человеке ставлю крест.

ORM недостаточно абстрактен. Все равно БД вылазит и дает о себе знать. А, значит, лучше с этим работать посредством терминологии и инструментария ее стандартной поставки

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

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

Еще она сильно завязана на поставщика. Конкретная СУБД - это самый серьезный vendor locking. А тут еще лочишся на поставщика ORM и целиком зависишь от его желания поддерживать твою СУБД.

что программировать нужно только в машкодах

Для пыходурачка SQL = машкоды, так и запишем.

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

JSONField мапится на json поле postgres.
И я могу через orm искать по каким-то вложенным полям в json

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

>MyModel.objects.filter(jsonfield__something__something='foo')

я давно этим не занимался, но вот как ты конкретно через приведенную тобой фигнюшку заставишь его сделать такой запрос:

where i.dev_service_field @> '{"legacy_imp_from_n": 7382}'::jsonb;

причем мне нужно именно так, потому, что я именно так хочу и ВСЁ. Плюс я проверял, что мои правильные индексы правильного типа правильно работают в этом случае.

сейчас ты начнешь тупить нести дичь, что надо не так, а иначе, что «ты неправильно делаешь» и т.д. скажешь что надо писать какой-то там HQL или адаптеры, плагины подключать фигнюшки для проброса оператора и т.д.

или допустим я хочу именно вот так:

where (i.dev_service_field->>'legacy_imp_from_n')::integer = 7382;

тогда как? опять никак? или опять изворачиваться? фигнюка твоя MyModel.objects.filter будет работать?

:-) https://github.com/BertrandBordage/django-cachalot дописал одну строчку и у тебя запросы кэшируются и инвалидируется автоматически.

вынужден все время держать в голове ее сущности

Я вот сейчас пишу crud для внтуреннего пользования. Большой нагрузки нет. Так что можно вообще не парится. Индексы указал и ладно. Хотя большинство запросов всё равно простые, ты их никак лучше без orm не напишешь.

И таких проектов миллион. Большинтсво веб сайтов тоже.

А на многих других проектах у меня вообще nosql.

Я как то пытался применить орм для своей игрушечной базы со спортивной статистикой, и быстро сломался, так сложно и вырвиглазно делаются простые вещи. Не знаю насколько примитивной должна быть структура БД, чтобы орм не причинял боли. Блог с тремя таблицами? Представить натягивание орма на промышленные схемы не могу, все какое-то жесткое порно представляется.

Еще она сильно завязана на поставщика. Конкретная СУБД - это самый серьезный vendor locking

насколько мне известно, на практике только 0,00000000001% проектов переходят с одной RDBMS на другую (потому, что 99% проекто умирают сразу после запуска, а еще 1% переписывают на новую хипстерскую технолгию, т.е. не до базы им). это выдуманная «полезная фишка». кроме того, они же говорят «орм не запрещает писать голый SQL, когда приходится» (кстати приходится сразу же). получается портабельность у ORM-нутого проекта... правльно такая же никакая что и у не ORM-нутого.

теперь «прикол»: те запросы которые не потребовали голого SQL в ORM - они и так перенеслись бы на другую базу (раз они настолько простые), т.е. получается их тоже можно было просто писать на SQL, и они выполнились на новой базе с тем же результатом.

кроме того, если делать проект чтобы агностик, то ты упрешься в общее подмножество. теперь вопрос: sqlite-то будешь учитывать? а то ведь с ним общее подмножество сокращается до select foo from bar.

нет никакого «SQL» есть mysql-овский sql, есть sqlite-товский sql, есть постревский sql и так далее

Я вот сейчас пишу crud

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

Выше я написал, что для простенького сайта почему бы

неправда

потому что в вебе нужно вывести комментарии к статье из таблицы id/parent_id. вывести 1) в правльном порядке по дате И по кто-кому-отвечал 2) одним запросом 3) с уже расчитаным уровнем вложенности (в итоге полезно для отступа в верстке). Для этого нужен recursive cte (и плюс еще массивы) запрос получается сточек на 5 и работает молниеносно. Но ORM не может этого. Таким образом, ORM не работает даже в вебе.

насколько мне известно, на практике только 0,00000000001% проектов переходят с одной RDBMS на другую

Есть поставщики, которые поддерживают сразу несколько СУБД.

нет никакого «SQL» есть mysql-овский sql, есть sqlite-товский sql, есть постревский sql и так далее

Оно-то понятно. Но в рамках проекта это такая константа, потому и говорю - SQL. Но, используя ОРМ, тебе надо еще согласовывать версии ОRМ и СУБД. Замена ORM по затратам равна переписыванию на новую СУБД.

In [34]: r=session.query(Report).filter(Report.sro['legacy_imp_from_n'].astext.cast(Integer)==3782)

In [35]: r.all()[0].sro
Out[35]: {'legacy_imp_from_n': 3782}

и т.д.

Но ORM не может этого.

Ну ХЗ. Может какой-то из пачки ОРМ-ов с таким справится без скатывания в ручной SQL. Я ORM-ов с кешами второго уровня наелся еще когда деревья были большими. И проблемы с ними решаются их отсутствием.

Это как раз ынтерпрайз. И поддерживать это намного легче, чем тонны sql лапши. Тем более что это не какая-то экзотика, есть куча программистов знакомых с этими фреймворками и ORM.

насколько мне известно, на практике только 0,00000000001% проектов переходят с одной RDBMS на другую

Отож. Гораздо чаще меняют не СУБД, а язык для морды (шок для пыхеров). Так что если хипстор приколотил себе яйцы к орму, будет переписывать вообще всё.

Это как раз ынтерпрайз.

твое

Я вот сейчас пишу crud для внтуреннего пользования. Большой нагрузки нет. Так что можно вообще не парится. Индексы указал и ладно. Хотя большинство запросов всё равно простые, ты их никак лучше без orm не напишешь.

выглядит как простенькая внутренняя тулза, которую проще выкинуть, чем изменять.
У меня на 2-х предыдущих работах были системы, унаследованные еще из 80-х. И где будет твой модный ORM, когда надо все это говно мамонта поддерживать 24/7? Тут только при попытке обновить версию СУБД косяки лезут, недопустимые в экономике и управлении производством.

r=session.query(Report).filter(Report.sro['legacy_imp_from_n'].astext.cast(Integer)==3782)

• т.е. ты гарантируешь что в результирующем sql будет @> оператор? а как сделать -> а как сделать ->> оператор?
• как управлять foo ?| bar против bar ?| foo
• как осуществляется работа с ltree и его операторами? опять никак?
• вообще это треш. filter(Report.sro - даже воспринять это не могу.

язык для морды

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

Господа, вопрос по существу. Про работу с БД в Питоне.

Как быть с бесконечным перекладыванием данных из курсора в dict/namedtuple и обратную сторону?

Мне нужно писать именно нативные SQL-запросы (и select и dml), но вот вся эта возня со объектом (структурой данных), именами колонок и именами ключей dict/namedtuple сильно достает, особенно когда таблиц много. Есть ли какие-то библиотеки готовые чтобы как-то автоматизировать это?

Как быть с бесконечным перекладыванием данных из курсора в dict/namedtuple и обратную сторону?

В смысле, в обратную сторону? Изменить значение в результирующем словаре и чтоб оно отобразилось в БД?

Я написал твой нижний пример astext это -->. без astext это ->

@-> это .contains

даже воспринять это не могу.

Что тут воспринимать? Report это таблица. sro название колонки. У меня просто такая таблица была под рукой с json полем

ак осуществляется работа с ltree и его операторами? опять никак?

http://sqlalchemy-utils.readthedocs.io/en/latest/_modules/sqlalchemy_utils/ty...

http://sqlalchemy-utils.readthedocs.io/en/latest/data_types.html#module-sqlal...

Что значит опять? Я же тебе показал что всё это элементарно делается. Просто ты рассуждаешь о вещах с которыми не работал вообще.

Во-первых, лучше так:

cu.execute('... SET col1=?, col2=?, col3=?', (o['prop1'], o['prop2'], o['prop3']))

Просто ты рассуждаешь о вещах с которыми не работал вообще.

Я как раз таки с ними работал, лол. Но не через ORM

Т.е. в этой твоей алхимии реализованы все особые типы данных постгреса и их операторы? и с полнотекстовым поиском тоже? т.е. доступ к tsvector, tsquery, tsrank?

Ну, могу только похвалить сообщество алхимии и тебя за глубокие знания алхимии.

Судя по всему ты потратил немало сил на изучениее алхимии, скажи если не трудно, как заставить ее сделать запрос, предположим, с WITH RECURSIVE который при этом динамически строит временно массив? Или в таких случаях рекомендуется напрямую его сразу написать на SQL?

или ты спрашиваешь возможен ли он

скорее справшиваю «возможен ли». может кто натыкался на какие-от удобства, но без ОРМ

(конкретно в psycopg %s это и есть безопасный ? плейсхолдер)

Но не через ORM

Я говорю про ORM. В мощных ORM можно писать практически любые запросы.

реализованы все особые типы данных постгреса и их операторы

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

и с полнотекстовым поиском тоже?

ага http://docs.sqlalchemy.org/en/latest/dialects/postgresql.html#full-text-search

WITH RECURSIVE который

with recursive там есть, но я им не пользовался, как оно работает я не в курсе.

Вот тут есть пример http://docs.sqlalchemy.org/en/latest/orm/query.html#sqlalchemy.orm.query.Quer...

скорее справшиваю «возможен ли»

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

конкретно в psycopg %s это и есть безопасный ? плейсхолдер

Странно, почему они отказались от стандартного?

Странно, почему они отказались от стандартного?

да, с толку сбивает. http://initd.org/psycopg/docs/usage.html#passing-parameters-to-sql-queries

там допустимы несколько вариантов https://www.python.org/dev/peps/pep-0249/#paramstyle

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

Понял, спасибо. Правда, пугает объем документации по алхимии.

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

Спасибо. Давно не писал на Python. А у них там DBAPI сильно обновился.

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

На сколько я знаю так или иначе явно или не явно но для ручного управления транзакциями тебе придётся сделать где то бегин и коммит.

Ну собственно там точно так же: делаешь бегин и делаешь коммит.

По поводу «sql без лапши», как я понял твой аргумент можно перевести в другую плоскость:

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

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

Тут то же самое - пофиг какой код генерирует орм пока это никому не мешает. Важно, что результат ожидаемый и что сделать с использованием ОРМ заметно проще чем без. А когда надо будет оптимизировать, тогда нужно будет написать соответствующие запросы руками. Всё как во взрослом мире.

А возвращаемый результат я специально для тебя описал в комментарии к print_r , кстати.

вынужден все время держать в голове ее сущности

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

У тебя явные проблемы с логикой.

сделать с использованием ОРМ заметно проще чем без

Это что например сделать с ORM проще чем без? На практике исключительно примеры обратного.

Странно такое слышать. Вы вообще знакомы с реальными задачами SQL за пределами самых элементарных конструкций типа джойнов?

Про работу с БД в Питоне

Ты тредом не ошибся?

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

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

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

Когда-то давно были попытки сделать мини-либу с наследованием вокруг встроенного php-шаблонизатора, но к успеху они не привели (в т.ч. из-за костылей с ob_start или как оно там).

Отсутствие во встроенном шаблонизаторе наследования и невозможность его надежно соорудить - основная причина использования twig.

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

она не то что протекает, ее вообще нет в ORM, т.к. ты вынужден с работать _непосредственно_ с концепциями базы _но опосреднованным_ кривым интерфесом, _причем_ добавляющим тонну уже теперь _своих_ концепций, т.е. куда большими усилиями.

посмотри на прмеры pawnhearts где они делают закат солнца вручную, т.е. на самом деле просто пытаются напечатать элементарную where clause со «особенным» оператором.

теперь предствь как они будут там писать другие простейшие запросы.

они просто дауны, что с них взять.

Что мешает использовать plain SQL там где это необходимо?

Сложность поддержки возрастает двукратно. Теперь у тебя и орм-запросы, и sql-запросы в разных местах. И два разных интерфейса.

Не вижу никакой сложности. ORM позволяет точно так же исполнять raw запросы, возвращая при этом тот же результирующий объект.
Твой бизнес слой даже знать об этом не будет.

вынужден с работать _непосредственно_ с концепциями базы

Ну можно зажмуриться и представить, что это модели предметной области. До первой выборки сложнее select foo from bar. Насчет приколов, в рельсах вот вообще не поддерживаются из коробки составные первичные ключи. Я долго ржал когда узнал. И пишут эти умники в доках: составные ключи - это неправильный дизайн. Да, все что не влазит в красивенькую картину мира хипстора - неправильно, кто бы сомневался.

ORM позволяет точно так же исполнять raw запросы

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

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

А сам запрос ты впендюришь где?

Там же где и остальные(не знаю что там у вас в похапе модно, репы или DAO).

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

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

исполнять raw запросы, возвращая при этом тот же результирующий объект

алло! какой «тот же» объект? половина данных которую возвращает СУБД это как раз таки _ответы_, а не данные (т.е. не элементарные хранимые свойства этих объектов).

заводить объекту калькулируемые свойства?

но что если эту информацию невозможно вообще прицепить ни к какому объекту? (что случается так же часто)

ну я понял, веб-хелловордщики считают, что таких задач не бывает и вообще «это неправильно»

Алё, маппишь любой ответ на любой объект.

подкрутить настройки централизованно

Ещё лучше - крутить настройки представлениями и процедурами самой БД, чтобы в «пыхе» почти не было шансов писать портянки сложных запросов. Да и не только в «пыхе».
В 1с как-то подглядел - она же целый MS SQL Server использует тупо как хранилище таблиц. Это как купить Лексус, только для того чтобы в багажнике картошку хранить. Тут хоть чем обмазывайся, если голые таблицы дергаешь.
ORM.. Ну, да, сдаюсь, согласен. С ним, действительно, выглядит красиво у AndreyKl. Следующий раз попробую.

Я вообще тут провожу агитацию против орма. Но если уж рукожопы выбрали орм, надо ему следовать, а не читить «вот тут мы sql пробросим, никто не заметит». Просто потому что рукожопы, выбравшие орм расписались заранее в неосиляторстве sql, и конечно ничего хорошего из их запросиков не выйдет.