SQLAlchemy для Django

http://krivushinme.tumblr.com/post/8705402445/sqlalchemy-for-django-with-aldjemy
  • Перевод
image Я не люблю Django. Я не люблю Django ORM, Django templates, Django forms и еще множество вещей в Django. Но у Django есть определенное преимущество — многие используют Django, практически любой python-программист знаком с джанго. Поэтому приходится мириться с недостатками этого фреймворка, но никто не мешает облегчать себе жизнь, используя действительно хорошие python библиотеки, например SQLAlchemy.

Что в SQLAlchemy лучше чем в Django ORM? Это главный вопрос, который я слышу от Django guys1, и у меня есть на него ответ — SQLAlchemy может выразить любой SQL запрос (ну 80-90%), в отличие от Django ORM, в котором можно выразить только весьма простые вещи.

И в некоторых Django проектах возникает необходимость в сложных запросах, на которые стандартный ORM неспособен. Условно предположим, что в момент создания проекта считалось, что Django ORM вполне хватит. Для решения можно писать чистый SQL или воспользоваться SQLAlchemy. Я за второй подход, так как чистый SQL плохо поддается DRY-фикации.



Какие недостатки при использовании SQLAlchemy? Нужно описать структуру данных для этой библиотеки отдельно, так как SQLAlchemy и Django ORM не совместимы, да и не было такого плана у их создателей. Также вы можете попробовать построить модель данных по структуре из БД. Тоже вариант, но всплывают тонкие моменты, когда собственно БД еще нет. Я пошел по другому пути и построил структуру по джанго моделям в своем проекте Aldjemy.

Для использования вам просто нужно добавить `aldjemy` в конец INSTALLED_APPS, и aldjemy пройдется по всем моделям и добавит к ним аттрибут `sa`.

Попробуем, запускайте ./manage.py shell_plus и введите:

User.sa.query.join(User.sa.user_groups).join(User.sa.user_groups.property.mapper.class_.group).filter(Group.sa.name=="GROUP_NAME")


Стоп, нужно указывать все join-ы явно? Конечно, это же SQLA, и в SQLA запросы строятся с явным указанием всех join-ов и прочего. Но на самом деле, надо ли использовать SQLA для выборки пользователей в группе? Конечно нет! SQLA придет на помощь в тот момент, когда вы будете писать сложный запрос, направленный на оптимизацию, на ускорение генерации страницы — и здесь возможность написать именно тот запрос, который вам хотелось, будет благословением.

Проект на github.

Или на PyPi:
pip install aldjemy


1. Django guys это такие ребята, которые упорно не желают видеть недостатков Django. Более того — да они даже не в курсе про множество библиотек за пределами этого узкого Dj-мирка.

Из документации: But aldjemy is not positioned as Django ORM drop-in replacement. Its helper for special situations.

Пример кода, который вы так просите habrahabr.ru/blogs/python/128052/#comment_4231276
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 303
  • +14
    Ну по моему не кто не говорил что django orm идеальна, и сами разработчики говорят что они покрывают самые базовые вещи, а всё что за пределами то используйте пожалуйста сырые запросы sql или что либо иное, при этом orm покрывает 90% всех потребностей. Но есть другая проблема, так называемые ваши ребята не видят не только что за пределами, но и то что есть из коробки, большая часть вопросов решается прочтением документации (есть и сеты и F и т.п), а не криками как всё плохо и бежать искать что либо иное. Вопрос в правильном выборе инструмента, и если изначально видно что будет сложная структура, то это уже другой разговор.
    • –7
      Я отлично знаю пределы возможностей Django ORM. Ни фига они не покрывают, достаточно шаг влево, и капут. Все эти примочки типа F, annotate и тому подобное, это костыли к изначально кривой идее. И то, что «сами разработчики» знают об этом, не делает SQLA ненужным. Когда уже запрос стал достаточно сложным, надо брать SQLA.

      Сказать вам что было видно стартующему проект, для которого была сделана Aldjemy, я не берусь. Но думаю он не рассчитывал на некоторые use-case проекта, которые возникли позже.

      В общем «не учите меня жить», будут такие же проблемы возьмете aldjemy и решите.
      • 0
        Может проблема в том, что не надо использовать Django для проектов в которых есть шаги в сторону? Есть прекрасная ниша в которой django рулит и все быстро и красиво получается. А то как начинаешь задумываться о шаблонах, формах, скафолдинга и магии и потом о том как это можно прекрасно все избежать используя что-то другое.

        А то что начинают на Django CRM'ы писать не от большого ума.
        • +4
          Не всегда вначале пути проекта видно, куда он там идет. Джанго берется по привычке и вперед. А выкидывать старый проект из-за некоторой его части, с которой можно в принципе разобраться — зачем?

          А так я полностью согласен на джанго не писать :)
          • 0
            Мне не нравится эта экспедиция, мне не нравятся эти мотросы, и вообще мне ничего не нравится! © м/ф «Остров сокровищ»
            youtu.be/IHui3_d67AU
      • +1
        в 2008-м году начинал писать на django интранетовский сайт для работы именно из-за большого сообщества, когда дело дошло до join-ов, фильтров, связке более двух таблиц код стал пухнуть, как на дрожжах. Вьюхи всех проблем не решают, да и в БД не хотелось лезть. Еще с URL-ами в django перемудрили.
        В итоге переехал на Pylons+SQLAlchemy(ныне Пирамида), по архитектуре, ИМХО, он на порядок лучше и прозрачнее Django.
        • –1
          не знал, что есть «истинные» django-дрочеры, аж карму опустили :)
          • 0
            Не уверен про джанго, а вот нелюбителей пирамиды достаточно.
      • +6
        Никогда не понимал таких статей. Так и хочется крикнуть — Люди! Выбирайте инструмент по задаче!
        • 0
          Надо знать плюсы и минусы инструмента и на основе этих знаний делать выбор. Подобные материалы позволяют узнать недостатки и достоинства, но в большинстве своем они однобоки и практически бесполезны.
          • +1
            Это статья о вполне конкретной вещи, а не сравнительный анализ SQLA и Django ORM — нечего там анализировать.
          • +1
            Есть такая тема, что инструмент могут выбрать задолго до вас. Плюс к тому начать писать на джанго многим легче, чем на SQLA.

            И SQLA инструмент по задаче — есть проблема на старом проекте со сложными запросами — берем SQLA и решаем.
            • +1
              > Есть такая тема, что инструмент могут выбрать задолго до вас.
              А в этом случае статья тем более бессмысленна, т.к. выбор уже сделан и работаешь с тем что дали. Если только для собственного развития.

              > Плюс к тому начать писать на джанго многим легче, чем на SQLA.
              Да и сравнивать Django и SQLAlchemy некорректно.

              Пишем на python, а это все инструменты облегчающие нам жизнь. Ведь можно взять джангу приправить ее алхимией и завернут в джинжа.
              • 0
                >> А в этом случае статья тем более бессмысленна, т.к. выбор уже сделан и работаешь с тем что дали. Если только для собственного развития.

                А вы точно читали статью? Александр, плохо рубить с плеча незнакомый текст, вы хоть ознакомьтесь с ним, чтобы рубить предметно.
                • +2
                  Читал и не в коем случае не собираюсь как-то «рубить» или говорить что она не нужна, не вырывайте мои слова из контекста. Я приверженец подхода инструмент под задачу, когда достаточно Django ORM — использую его, когда нужна алхимия — почему бы нет. ORM в принципе штука сомнительная (у меня не такой большой опыт использования алхимии, может она и генерирует хороший SQL). Но вот смотрю я на несколько проектов часть из которых довольно нагруженные и там в основном одни прямые запросы.

                  Еще раз, я не к тому что хороша та или иная библиотека (модуль), а к тому что у каждый инструмент решает свою задачу. А в статье есть несколько сомнительных высказываний.

                  P.S. Неплохо было бы привести примеры запросов как они выгладят на django orm и с использованием aldjemy, а так же что генерируют обе библиотеки и включить их в статью.
                  • +2
                    Да не нужно примеров. Когда вам понадобится SQLA, вы об этом точно узнаете. Просто пока она вам не нужна — ну не объяснить. Да, у вас прямые. Это же клево! А у меня уже навороченные и select_related спасать перестал.
                    • +1
                      Не, если у вас мало опыта работы с SQLAlchemy то пожалуй можете и не догадываться насколько она мощнее. Попробуйте с ней поработать поплотнее — сразу поймете.
                      Я не троллю, просто сам под Django разрабатывал, а потом на Pylons занесло. Сам по себе Pylons так себе, но из за SQLAlchemy на Dkango не хочется возвращаться.
                      • 0
                        А вы можете сравнить SQLAlchemy и Doctrine2 (PHP если что)? Вот мне после знакомства Doctrine2 на любую ORM, реализующую ActiveRecord возвращаться не хочется, даже будь она под Рельсами или Джанго, я лучше на голом пхп писать буду, а уж учитывая наличие symfony2 или, хотя бы, Sylex…
                        • 0
                          Я только с Propel работал из пхп-шных год назад последний раз. Но пропель это огромный кодогенератор и я с ним как то не очень подружился. Не понравилось кажется еще что можно одно и то же несколькими способами получить, деталей не помню. Задавать модели XML-ем тоже не нравилось. С Doctrine я не работал.
                          • +2
                            Вообще-то, что Doctrine2, что SQLAlchemy реализуют паттерн DataMapper, а не ActiveRecord, как DjangoORM и та же KohanaORM под php.

                            По сути, Doctrine2 — это SQLAlchemy на PHP. Что там сравнивать? :)

                            Если кто не в курсе, фишка DataMapper'а как раз в том, что поля ORM-объекта могут быть откуда угодно (вычисляемые sql-выражения, memcached или лежать на другой машине, с доступом по WebDAV), а не только из базы и при чтении/записи в поля объекта мы можем описать логику чтения/обновления этих данных. ActiveRecord же жестко привязан к записям в таблице.

                            Ну и по моему опыту работы с SQLAlchemy могу сказать, что там очень круто и по-уму реализовали движок sql-выражений. Выдает достаточно оптимизированный код даже на сложных запросах. Крайне редко приходилось прибегать к голому SQL.
                            • 0
                              В общем-то потому и попросил сравнить, что один паттерн реализуют, который дюже нравится :) Интересно сильно ли реализации отличаются, если отбросить языкозависимые штуки. В той же Доктрине не только DataMapper, но и UnitOfWork
                              • 0
                                Кстати, вспомнил за что еще люблю SQLAlchemy — очень удобны в использовании перегруженные операторы — т.е. можно писать например
                                .filter(User.id >= 100)
                                вместо чего-то в стиле
                                User->id->gte(100)
                                Это мелочь, конечно. Но «Дьявол скрывается в деталях»
                                • +2
                                  С этим у алхимии все круто:
                                  The Unit Of Work system, a central part of SQLAlchemy's Object Relational Mapper (ORM), organizes pending insert/update/delete operations into queues and flushes them all in one batch. To accomplish this it performs a topological «dependency sort» of all modified items in the queue so as to honor inter-row dependencies, and groups redundant statements together where they can sometimes be batched even further. This produces the maxiumum efficiency and transaction safety, and minimizes chances of deadlocks. Modeled after Fowler's «Unit of Work» pattern as well as Hibernate, Java's leading object-relational mapper.

                                  www.sqlalchemy.org/features.html

                                  Поэтому я и назвал Doctrine2 алхимией под php. :)
                                  • 0
                                    Спасибо, тогда надо будет попробовать :)
                  • –1
                    Кстати, забыл совсем. Никогда не понимал вот таких поверхностных комментов от «экспертов».
                    • +3
                      Если честно не понял кусок про эксперта. Но вы в общем-то рекламируете определенную библиотеку и сравниваете ее с django orm, при этом не приведя ни одного примера использования обоих решений для одной задачи.

                      Не любите django? Так не используйте. Не нравится какая-то одна ее часть — замените аналогом, что вы в общем-то пытаетесь сделать, но при этом ваш материал больше похож на рекламный, при том что сравнение было бы куда интересней и полезней.
                      • 0
                        Да нет же. Я про интеграцию — когда нужно, есть путь как прикрутить SQLA в проект, вот и все. А убеждать в пользе SQLA я никого и не собирался. Просто поделился своим решением.
                    • 0
                      Иногда переписывать проект во второй раз сложно себя заставить или времени не хватает, вот и вырастают такие франкенштейны, а с первого раза это надо оочень хорошо провести планирование и заморозить на время разработки заказчика.
                      • 0
                        Это не такой уж франкенштейн, вполне рабочее решение. Генерировать ли модель данных по Django моделям, или брать какую-то обертку для этих целей — такая уж ли это большая разница?
                    • +14
                      настолько толсто, что аж спорить не хочется.

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

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

                      А вот что хотелось бы узнать у автора, это всерье ли он считает, что

                      User.sa.query.join(User.sa.user_groups).join(User.sa.user_groups.property.mapper.class_.group).filter(Group.sa.name==«GROUP_NAME»)

                      легче читается и проще поддерживается чем аналогичный sql запрос?
                      • +1
                        Привычка выкинуть при прочтении половину строк сильно подводит вас.

                        > А вот что хотелось бы узнать у автора, это всерье ли он считает, что
                        Конечно нет, что видно из текста:
                        Но на самом деле, надо ли использовать SQLA для выборки пользователей в группе? Конечно нет!

                        Никто не предлагает заменять ORM, я предлагаю решение для сложных случаев.
                        • –3
                          > оставим за бортом вопрос ускорения генерации страницы с помощью огромного джоина.

                          Кстати, а что по вашему делает select_related? Опять «эксперт»?
                          • –3
                            select_related это костыль.
                            • –4
                              Эксперт очевидность утверждает, что в реальной жизни разбивка select_related на 2 запроса дает избавление от головной боли и +500 в карму
                              • +5
                                100%, наивная реализация джойна в вашем «экспертном» коде порвет джойны в БД, которые написали хлюпики-ботаны из CS.
                                • +1
                                  Порвёт на раз, потому что большую часть приджойненых объектов я подтяну из кеша.

                                  select_related() с явным указанием что джойнить работает отлично.
                                  • 0
                                    Я про то и говорю :) просто mjr27 предлагал сделать вместо одного запроса с джойнами запросов по числу нужных моделей. И кеш видимо свой сделать.
                          • +1
                            Зачем зацикливаться на админке, моделях и т.п. вещах? Да, они облегчают жизнь, но это не панацея, ту же админку, если вам нужно больше предлагаемого функционала — проще и быстрее написать свою.

                            Еще раз Django это инструмент облегчающий нам жизнь, коих кстати много, то что он самый распространенный, не делает его лучшим, но отказываться от джанги из-за админки как и выбирать ее из-за этого — имхо глупо.
                            • 0
                              Отказываться — да, выбирать -нет.
                              • +1
                                Выбирать джанго из-за админки — не глупо, экономит очень много времени, и даже если она вам не подходит для отдельного приложения или модели, то нужно будет переписать только для них, а для всего остального будет работать стандартная. Да и возможности кастомизации админки джанги весьма велики, так что полностью переписывать возможно и не понадобиться.
                                • 0
                                  Админка у джанги страдает родовой травмой — она начата не с того момента. Хорошие и правильные идеи админки лежат в Svarga.

                                  Почему — админка джанги заточена на CRUD. Все ее возможности в этой плоскости и располагаются. Админка в Svarga построена без завязки такой жесткой на модели. То есть базово кирпичик Сварго админки начинается с пункта меню. Что за ним будет, список ли моделей, или график загрузки сервера, выбор разработчика. И то и другое вставляется одинаково легко.

                                  Собственно Bundle я из Svarga во Flask уже портировал, можно и над админкой подумать.
                                  • 0
                                    > Собственно Bundle я из Svarga во Flask уже портировал, можно и над админкой подумать.

                                    Было бы неплохо.
                            • +3
                              Из чистого любопытства. Привидете, пожалуйста, пример когда это может быть полезно. Если я правильно понимаю пример из статьи, то он стандартным джанговским орм решается примерно так (по памяти)

                              class User(models.Model):
                              name = models.CharField()
                              groups = models.ManyToManyField(Group, through='Membership')

                              class Group(models.Model):
                              name = models.CharField()
                              members = models.ManyToManyField(User, through='Membership')

                              class Membership(models.Model):
                              user = models.ForeignKey(User)
                              group = models.ForeignKey(Group)

                              ну и соответсвенно потом можно как и User.groups — список групп, так и Group.members — список участников.

                              или я что-то пропустил?
                              • –2
                                Да, вы пропустили прочесть статью. Статья о том, как ничего не править в проекте, а взять и нафигачить запрос на SQLA без головной боли и без переопределения моделей. Такой вот финт для застарелых проектов, которые переписывать слишком долго.
                                • +4
                                  похоже вы пропустили прочесть мой комметарий. было интересно зачем прикручивать SQLA. на реальном примере. ибо приведенный вами пример очень сильно притянут за уши.
                                  • –2
                                    Это пример написания запроса был, если что. А не пример как надо делать. И об этом там же и написано:
                                    > Но на самом деле, надо ли использовать SQLA для выборки пользователей в группе? Конечно нет!
                                • +3
                                  Вот, что попалось на глаза из текущего проекта:

                                  return (SettlementLine.query(Settlement, Payment, Order, Event)
                                          .join(Payment)
                                          .join((Settlement, SettlementLine.psp_settlement_line_id == Settlement.id))
                                          .join(Order)
                                          .join(Event)
                                          .outerjoin(IdsLine)
                                          .outerjoin(IdsBatch)
                                          .filter((SettlementLine.batch == None) &
                                                  (SettlementLine.settle_after < datetime.now()) &
                                                  (SettlementLine.source == SettlementLine.Source.ECOMMERCE) &
                                                  ((Order.domain_id == Route.domain_id) |
                                                   (IdsBatch.status == IdsBatch.State.RECEIVED)))
                                          .all())
                                  

                                  • 0
                                    надо бы еще на можели взглянуть, но на вскидку

                                    qs = SettlementLine.filter(batch=None).filter(settle_after < datetime.now).filter(SettlementLine.source=SettlementLine.Source.ECOMMERCE))

                                    result = qs.get( Q(order_domain_id=Rout.domain_id) | Q(idsbatch.status = idsbatch.state.RECEIVED) )


                                    не уверен насчет последнего Q объекта, просто не понял логику связи. но как то так.
                                    • 0
                                      «SettlementLine.query(Settlement, Payment, Order, Event)» вытаскивает 5 объектов в каждой строке. Типа, «for settleline, settle, payment, order, event in thisquery» было бы.
                                      • 0
                                        джанго вытащит их ленивыми. ну или select_related поставить впереди. это при условии наличия связей между моделями, конечно.
                                        • 0
                                          Ленивыми == не вытащит. select_related работает только для прямых запросов. И разве ему можно уже указать «этого тащи, этого не тащи»?

                                          Бтв, IdsBatch — он через Order, Event, IdsLine, IdsBatch. Так что это будет что-то типа Q(order__event__idslines__idsbatches__status = RECEIVED). Я уже умудрился забыть, обратный джойн в джанге работает?
                                          • 0
                                            с чего вдруг ленивыми == не вытащит? вытиащи но у вас будет пеформанс хит при обращении.

                                            >И разве ему можно уже указать «этого тащи, этого не тащи»?

                                            таки да.

                                            >Q(order__event__idslines__idsbatches__status = RECEIVED). Я уже умудрился забыть, обратный джойн в джанге работает?

                                            все равно это проще чем та кверя, что привели вы. обратный джойн работает, да
                                            • +1
                                              > с чего вдруг ленивыми == не вытащит? вытиащи но у вас будет пеформанс хит при обращении.

                                              Не вытащит — в плане они не будут у меня, это будет еще один запрос (ну, не один, десяток).

                                              > все равно это проще чем та кверя, что привели вы. обратный джойн работает, да

                                              Да не, не проще. Особенно учитывая, что у меня в ipython'e автодополнение для алхимии работает, а для джанги, очевидно — нет (кто ж дополнит order__event__idslines?). Энивей, я просто навскидку что-то вытащил из кода, и не подбирал специально что-то феерическое.
                                              • +4
                                                вы эта, критерии сразу озвучивайте. а то получается:
                                                — джанговскийо орм гавно, вот так он не может…
                                                — да, гавно конечно, но может…
                                                — неее, так не считается. это на ipython не сработает.

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

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

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

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

                                                а так, получилась помойка с минимумом конструктива. причем автор считает, что он душка-зайка, никому не хамит, а это его «эксперты» одолевают :)
                                                • 0
                                                  Что такое? Я сразу сказал, что одним запросом из джанго-орма не вытащить. У тебя будет по 5 (минимально) запросов на каждый SettlementLine, что ты обрабатываешь. Учитывая то, что я достаю их по 100 штук обычно, выходит 501 запрос. Всë, нашему приложению жопа.

                                                  Так что говно и не может.
                                                  • 0
                                                    Давайте может на конкретных примерах :)
                                                    Не ради померятся размерами, а ради чисто профессионально интереса)

                                                    Можете сделать запрос, достаточно сложный на sqla и вывести raw запрос который он формирует.

                                                    Я постараюсь сделать на джанго тоже самое — посмотреть насколько хуже оно там получается.

                                                    Интерес не ради «померяться», думаю это многим будет интересно )

                                                    • 0
                                                      Я уже показал три запроса, все три достаточно весëлые. Но у меня плохо сейчас со временем, я последние часы дорабатываю на текущей работе, так что сорри, нет времени меряться серьëзнее.
                                                    • 0
                                                      гдето изначально речь шла про количество запросов? вроде говорили про возможность выразить тот или иной селект через 2 разных орм.

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

                                                      ну и само по себе сравнение чуть странновато, джанго она ближе к DDD и его принципы старается использовать, а алхимия идет от структуры базы.
                                                      • +1
                                                        Критерии крутости — я на алхимии могу сделать и оно работает, а на джанге у меня не хватает времени всë обработать, приходится скатываться в raw sql, чего я абсолютно не хочу.

                                                        По-моему, это очевидный критерий.
                                                        • +1
                                                          нет, не очевидный. я на джанге на ро сиквеле сделаю так что работать оно будет на 40% быстрее и сожрет на 20% меньше памяти на каждый запрос, разработка займет в 2 раза меньше времени, новый человек разберется за 15 минут вместо 2х часов. (для *конкретного* кейса)

                                                          вот это я понимаю — критерии.

                                                          на всякий случай: это ирония.
                                                          • +1
                                                            Ну, серьëзно, неужели возникает ощущение, что я сижу и мечтаю переписать какой-то ужасный запрос на raw sql и весь код, который его юзает, измерить время, потом на джангу, и т.д.? Конечно, инструмент для задачи. У меня в задачах — сложное приложение со сложными запросами. Мне надо вытащить кучу данных и потом с ними дальше работать удобно. А в одном месте замутить raw sql, и дальше у тебя не объекты, а словарики и списки. Не очень приятно.

                                                            Если кажется, что джанговского орма хватает — я не против. Мне так тоже раньше казалось, и мне хватало, но иногда приложения бывают сложнее, а иногда проще.
                                                            • +1
                                                              джанги давно уже не хватает, есть масса решений в том числе и для подключения алхимии. наш профессионал только недавно до этого дозрел, видимо.

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

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

                                                              собственно мои вопросы были из любопытсва понять с чем столкнулся профессионал и сравнить с тем с чем когда то столкнулись мы.
                                                              • 0
                                                                Усомнился?
                                                                • 0
                                                                  в чем?
                                                                  • 0
                                                                    > написал, что джанго-орм гавно привел пример подтверждающий обратное и самже в нем усомнился.

                                                                    Я усомнился в примере? Пример мозг не взрывает, я не искал специально, но тем не менее это 1 запрос, а не много.
                                                                    • 0
                                                                      Он имел в виду пример из топика. Я в нем не сомневался, просто отметил что в этом случае SQLA нафиг не нужен.
                                                                      • 0
                                                                        А, ок. Он просто начал разговаривать странным слогом и я потерялся в профессионалах.
                                                                        • 0
                                                                          там просто чуть ниже автор себя причислил к профессионалам, а всех остальных к «экспертам». Так что я исключительно ради соблюдения этикета, вдруг обижу человека
                                                                      • 0
                                                                        речь шла про автора. автор усомнился в приведенном в статье примере.
                                                                        • 0
                                                                          Но он не усомнился. Он просто сказал, что вот так можно делать запросы. База, типа, чтоб было понятно, куда смотреть.
                                                                          • 0
                                                                            /*Стоп, нужно указывать все join-ы явно? Конечно, это же SQLA, и в SQLA запросы строятся с явным указанием всех join-ов и прочего. Но на самом деле, надо ли использовать SQLA для выборки пользователей в группе? Конечно нет!*/

                                                                            тоесть так делать можно, но, конечно, не стоит. это и означает сомнение в примере. и захотелось посмотреть на реальную ситуацию
                                                                            • 0
                                                                              Никакого сомнения. Пример с потолка, просто демонстрация того как выглядит запрос в SQLA. Да еще и отличное предостережение, что не надо микроскопом гвозди то заколачивать.

                                                                              Вы сами то приведите хороший пример. Это сложно достаточно сделать, вырвать из контекста и тому подобное. Поэтому и берется простой дубовый пример с дисклеймером.
                                                                  • –1
                                                                    С чего и надо было начинать.

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

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

                                                                    От джанго я давно и с успехом отказался везде, где это возможно. Но уже неоднократно здесь указывалось, что отказаться от нее в старом проекте практически невозможно, особенно учитывая большой поток feature запросов от заказчика. А так я предпочел бы не пинать труп, и забить на джангу в комплексе.
                                                        • –2
                                                          Автор считает, что никому не обязан представлять никакие юзе кейсы, достаточно идеи и рабочего кода.

                                                          Имею право послать всех «экспертов» которые думают иначе.
                                                          • 0
                                                            да да да. только я знаю истину и несу ее свет! вы «эксперты» еще не доросли до моего величия, поэтому я вас посылаю!

                                                            кхм, извините, нимб не жмет?
                                                            • –2
                                                              «эксперты» явно не доросли. Те, которые доросли, юзе кейсы не просят, они сами все знают. Они себе добавили ссылочку в закладки, и применят aldjemy в подходящем проекте.
                                                              А ради товарищей, которые хотят чтобы им значит пояснили предметно, разжевали и в рот положили, напрягаться не вижу никакого смысла. Я таких товарищей не люблю принципиально.
                                                              Поэтому я вижу идеальный случай этого топика среди профессионалов так — пост, и вопросы в комментах про особенности реализации. И типа почему сделано так, а не так? Может еще предложение полезное.
                                                              А то что я вижу это унылый троллинг от интеллектуалов (сарказм).
                                                              • 0
                                                                судя по всему, не жмет. клёва.
                                                                • +1
                                                                  Поэтому я вижу идеальный случай этого топика среди профессионалов так — пост, и вопросы в комментах про особенности реализации. И типа почему сделано так, а не так?


                                                                  Ну давай попробуем :-)

                                                                  1. Реюз Django connection в пуле — прикольно :-)
                                                                  2. Тесты, тесты. Хочу тесты, хотя бы простые, а то возникает много вопросов «M:M работает? Наследованные таблицы работают?».
                                                                  3. В целом, прикольная библиотека, в плане «полезной зарядки для ума» :-)
                                                                  • 0
                                                                    Реюз коннекта это кстати Владимир Михайленко сделал, за что ему спасибо огромное. Я же стартанул свою библиотеку от его интеграции SQLA в проект, и увел ее в сторону генерации модели данных по Django моделям.

                                                                    Тесты, да. Обычно я начинаю библиотеки с тестов. У этой они тоже есть, но лежат в секретном проекте. Придется написать отдельные, раз уж библиотека пошла в мир.
                                          • +5
                                            Питонщики нынче, судя по комментариям, с ядовитыми железами пошли…
                                            • 0
                                              Да ну тут как почитаешь «экспертов» в комментариях, которые SQLAlchemy в глаза не видели и требуют от меня доказать что оно лучше, так пожалуй коброй станешь.
                                              • 0
                                                так приведи пример-сравнение. многим сразу стало бы понятнее насколько sqla мощнее и гибче django orm :)
                                                • 0
                                                  Просто примеры выдирать из кода — ну там же не понятно будет что к чему. Придумать из головы — ну никто же не скажет «о, круто», скажут «а нафиг тут так сложно»? Несмотря на искусственность примера. Поэтому было желание к этому не скатываться, тем более что не о том статья.

                                                  Вот пример, но это именно вариант «ни фига не понятно зачем оно так»:

                                                  habrahabr.ru/blogs/python/128052/#comment_4231276

                                                  PS Не тыкайте. Это лично ваш выбор, беседовать на ты, он не обязан быть приятен собеседнику.
                                                  • +1
                                                    без примеров это вызвало не меньше вопросов, чем с хоть какими то примерами.

                                                    PS Вы можете просто не отвечать.
                                                    • 0
                                                      Почему же не отвечать, я же топик написал, чтобы развеяться за приятной беседой с умными людьми. Как выяснилось их много, даже чересчур. А в общем именно на это я и рассчитывал, я же знаю хабр и его уровень.

                                                      С примерами все идет не в то русло, начинаются какие-то странные предложения как решить проблему иначе — и все они сильно хуже и не решают поставленной задачи. На мой взгляд результат один — разговоры ни о чем.
                                                      • 0
                                                        я задаю вам вопросы не для того чтобы доказать что дж.орм крут или алчеми отстой.
                                                        Я иногда сталкиваюсь с ситуациями, как и многие, когда нужно более-менее юзабельно формировать\компоновать\собирать raw запросы.

                                                        Как вариант решения — параметризованные функции или классы обертки которые становятся более-менее универсальными и цельным объектами в коде.

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

                                                        Но я уже пожалел о том, что начал тут что-либо писать и спрашивать)

                                                        • 0
                                                          Вообще первые комменты как всегда пошли в русли «а чо а нафиг, а докажите мне что оно мне же нужно». Ну вот в этом русле и пошло. Были бы другие вопросы, были бы другие ответы.

                                                          Да, я понимаю, что было бы интересно. Парочку привели в комментах, на большее рассчитывать не стоит, у всех своих дел хватает.
                                                          • 0
                                                            Если ты людям что-то предлагаешь, то должен объяснить зачем им это и чем это лучше того, что у них есть. По-моему, очевидная вещь.
                                                            • 0
                                                              Вот как раз нет, ничем я людям не обязан. По-моему готовой реализации уже выше крыши для людей. Если я не хочу объяснять и спорить, имею право. Ведь объяснениями не заканчивается — начинается поток экспертных мнений, по типу джойны руками на стороне бека сделать. Поэтому лезть в этот шит очень не хотелось, но не удалось отбиться малой кровью.
                                                              Основной мотив вопрошающих это найти какой-нибудь изъян по их мнению в логике и накинуться с криками «ЫЫЫ, абырвалг, мы лучше знаем, джойны отстой».
                                            • 0
                                              Если у сабжа честный DataMapper то обеим руками за. Это надо почувствовать, что такое когда твои модели зависят только друг от друга!!!
                                              • +5
                                                Ура! наконец люди начали смотреть на вещи трезво.

                                                Кстати, есть еще одна реализация lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ от Армина Ронашера.
                                                Здорово то, что людей с пугавицами вместо глаз(читай Django gays) становится меньше. И многие начинают понимать, что за пределами django есть огромный мир интресных и мощных инструментов! И что python не начинается и не заканчивается на джанго. Не стану отрицать, django — гениальная вещь, в свое время ставшая революцией. Люди до сих пор плачут от счастья, переходя с PHP на python/django, но(!). Трудно остановить прогресс и пыливую мысль программиста, желающего упростить свой труд =) Теперь есть инструменты более мощные, гибкие, при этом намного менее ограниченные чем django.
                                                К примеру, я сейчас использую:
                                                — flask
                                                — wtforms
                                                — mongoDB
                                                — mongoalchemy
                                                — flask-mongo-admin.
                                                и не испытываю дискомфорта от того что что то не получается реализовать.

                                                И считаю себя счастливым человеком =)
                                                • +2
                                                  +1.
                                                  мой инструментарий:
                                                  — cherrypy
                                                  — wtforms
                                                  — python-mysqldb
                                                  — jinja2
                                                  — sqlalchemy
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                    • +1
                                                      > flask-mongo-admin? почему-то не гуглится
                                                      Написан мной, его нет в открытом доступе. Подготовлю версию, но чуть позже, если кому интересно =)
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                        • 0
                                                          Просто редактор содержимого базы. Регистрируешь модели и все. Сделан на основе wtfrms. Нет ровно никаких украшательств, которые есть в джанго админке. Просто. Работает.
                                                          =)
                                                        • 0
                                                          Строите формы по моделям mongoalchemy? Вложенные структуры поддерживаются?
                                                          • 0
                                                            1. Да.
                                                            2. Нет.
                                                            Выводится json в textarea, и редактируется там. Планирую с ним сделать json редактор на клиенте. Наброски уже имеются.

                                                            + еще добавил автоинкремент и свойство id к любому документу. По ним и шерстит админка.
                                                    • +3
                                                      Django gays???
                                                      • +2
                                                        Это не реализация, это рассказ как переехать на SQLA с джанго. А у меня библиотека, которая дает легкий путь к генерации SQLA запросов.
                                                        • 0
                                                          • 0
                                                            не, это совсем не то… По ссылке штука, которая позволяет в SQLAlchemy делать filter_by(entries__headline__exact='b2 headline 2'). В статье все как раз наоборот.
                                                            • 0
                                                              Сорри, это Ваша библиотека, наоборот )
                                                        • 0
                                                          Маны читать не пробовали?
                                                          Performing raw SQL queries
                                                          Complex lookups with Q objects
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                            • 0
                                                              > Когда ORM скатывается в raw SQL это очевидным образом fail, вам так не кажется?

                                                              почему?

                                                              орм пытаются быть универсальными, универсальность, обычно, накладывает ограничения, как по перфомансу, так и по функционалу. Если у орм есть вменяемый маппер, который сможет замапить результат голой сиквел квери в объекты, то что кроме религии, мешает это использовать? особенно учитывая, что все эти тонкости реализации остаются внутри репозитория, а наверх отдаются только объекты.
                                                              • –2
                                                                Да потому что сырой SQL практически невозможно написать так, чтобы можно было следовать DRY. Пока вы это будете делать — нафигачите еще одну либу.
                                                                • +1
                                                                  я так понимаю примеров подтверждающих ваши утверждения можно не ждать :)
                                                                  особенно в сопоставлении вместе с SQLA, ну как там аналогичный пример решается с соблюдением DRY.
                                                            • 0
                                                              Вы не читали ман, ссылку на который я дал. «Raw queries» и «Custom SQL» — разные вещи.
                                                              • 0
                                                                Ну конечно, прочитать ман по sqlalchemy я осилил, а вот по джанго нет. Вы точно так считаете?
                                                            • 0
                                                              Бал «экспертов» продолжается? Ну тоже значит рекомендую к прочтению www.sqlalchemy.org/docs/
                                                              • +1
                                                                Вообще-то я аргументировал неспособность автора адекватно оценить способности Django, которые он уверенно опустил.
                                                                Что в SQLAlchemy лучше чем в Django ORM? Это главный вопрос, который я слышу от Django guys1, и у меня есть на него ответ — SQLAlchemy может выразить любой SQL запрос (ну 80-90%), в отличие от Django ORM, в котором можно выразить только весьма простые вещи.

                                                                Так что причем тут ваш комментарий — мне непонятно.
                                                              • +1
                                                                Скажите, почему вы как эксперт без кавычек с мировым именем, не можете привести пример, подтверждающий необходимость того, о чем вы говорите.

                                                                Пример который вы привели в статье уже был опровергнут. на большее мирового имени не хватает?
                                                                • –1
                                                                  Эксперт-нечитаютопики, я этот пример сам опустил в той самой статье, которую вы не читали. Сравнение Django ORM и SQLAlchemy проведите для себя сами, мне это ненужно. Вам нужно, вы и делайте себе сравнительный анализ. Когда я решу написать статью «почему джанго орм сливает sqla», я ее так и озаглавлю.
                                                                  • +12
                                                                    Ага, краткий персказ обсуждение:

                                                                    Автор: Чуваки, смотрите к джанго можно прикрутить SQLA!!! потому что джанговский орм на многое не способен! и теперь вы можете выбирать мембершим вот так: User.sa.query.join(User.sa.user_groups).join(User.sa.user_groups.property.mapper.class_.group) и это клева чуваки, истину говорю вам.

                                                                    Чуваки: Ну ок, джанговский говно. но на нем мы мембершип выбираем вот так Group.members. Есть реальный пример когда SQLA будет полезнее?

                                                                    Автор: Да вы «эксперты» статью почитайте! там про то что можно в джанго орм заменить на SQLA! а не про то зачем это. просто можно и все. и это круто!

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

                                                                    Автор: Достали «экперты»! сравнивайте сами, я просто написал что можно. Нужны примерны — сами ищите. когда дорастете и поумнеете сами все поймете!

                                                                    Чуваки: ок.
                                                                    • +2
                                                                      Я привëл пару примеров, когда джанговский орм не годится, можешь поискать по комментариям и посмотреть.
                                                                      • 0
                                                                        «Чуваки» заменить на «эксперты которые не в курсе что такое SQLAlechmy и считают что автор должен им это пояснить». А я не считаю, что мне нужно вам это пояснять, для этого есть документация, ссылка на которую есть в этом топике.
                                                                        Тем не менее спасибо Александру за примеры.

                                                                        У меня есть пример, но он очень большой, могу дать маленький кусочек.
                                                                            def q_on_time(self):
                                                                                return self.make_query(
                                                                                        self.lproject_and_taskhistory_join,
                                                                                        (self.taskhistory_filters_statuses + self.task_not_canceled +
                                                                                         self.date_filter(Task.sa.completion_completed)),
                                                                                        (Task.sa.delivered_on_time, Task.sa.id)
                                                                                ).group_by(Task.sa.id).\
                                                                                add_columns( (Task.sa.delivered_on_time == 1).label('delivered') ).\
                                                                                from_self().group_by(*self.grouper).\
                                                                                add_columns(
                                                                                    (func.sum(expression.column('delivered')) / func.count(Task.sa.id)).label('on_time') 
                                                                                )
                                                                        


                                                                        Если оно вам поможет, пожалуйста. Если учесть, что это одна из 10 составляющих запроса, то как это выразить на Django ORM я вообще не знаю. Оно там в итоге еще и джойнится.
                                                                        • 0
                                                                          Уважаемый автор, а теперь попробуйте откинуть ваш апломб, и сказать как вот тут соблюдается DRY и как сильно вот это отличается от голой сиквельной квери.
                                                                          • 0
                                                                            А я скажу, без всякого апломба — этот кусочек служит для генерации 9 разных запросов.
                                                                            • 0
                                                                              тоесть меняем скл кверю на хранимую процедуру и проблема чудесным образом решается?
                                                                              • –2
                                                                                Да, и работает на всех БД, что характерно для хранимых процедур. Это магия «эспертов», у них все работает.
                                                                                • +1
                                                                                  тоесть у вас такой непростой проект, что вам то орм надо поменять, то базу? :)
                                                                                  • +1
                                                                                    Тесты на sqlite быстрее бегают.
                                                                                    • 0
                                                                                      Ну и можно увидеть пример хранимки, которая сделает то же, что и приведенный кусок?
                                                                                      • 0
                                                                                        примера не будет. я не готов либо переписвать ваш, либо придумывать какото свой который достоточно точно отразит проблему, чтобы вы не сказали потмо что эксперты опять чтото не поняли и все упростили.

                                                                                        сама возможность реализации в чем то вызывает сомнения?
                                                                            • 0
                                                                              Обратите внимание на код, параметры к self.make_query, параметр self.grouper и тп.
                                                                              • –1
                                                                                то что код возвращает кверисет это очевидно. спасибо, кэп
                                                                                • +3
                                                                                  Параметризованный запрос оно возвращает. То есть этот запрос, в зависимости от параметров, хорошо изменяется, и этой гибкости хватает на создание 9 весьма разных запросов. Получить это с raw sql у вас не выйдет, напишете реального франкенштейна.
                                                                  • 0
                                                                    raw SQL это однозначный костыль, который без оговорок усложняет поддерживаемость, поиск дефектов, внесение изменения в модель, плюс почти что исключает возможность наличие разных версий модели, если кратко, то это дырка в уровне абстракции.

                                                                    Каждое из его использований нужно особо выделять в документации и коде и при внесении любых изменений в модель просматривать все raw SQL соответствующего модуля.

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

                                                                    Если raw sql действительно неизбежен и вносится в код раньше заключительных этапов разработки, когда идет работа над увеличением производительности, то стоит начать думать о других инструментах.
                                                                  • +7
                                                                    Примеры сложных (и нужных, не сентетических) запросов нереализуемых с Django ORM, но реализуемых на SQLA в студию, пожалуйста.
                                                                    • +2
                                                                      В гугл, пожалуйста, за несентетическими запросами. А эта статья на о сравнении Django ORM и SQLAlchemy. Это для тех, кто это и так знает.
                                                                    • +5
                                                                      Take it, take it!

                                                                      return (order_models.Order.query(order_models.OrderLine, product_models.Product, v1, event_models.Event, rm.TicketwareUser)
                                                                              .join(order_models.OrderLine)
                                                                              .join((event_models.Event, event_models.Event.id == order_models.OrderLine.event_id))
                                                                              .join((product_models.Product, product_models.Product.id == order_models.OrderLine.product_id))
                                                                              .join((_Value, _Value.instance_id == order_models.Order.id))
                                                                              .join((_Field, _Field.id == _Value.field_id))
                                                                              .join((v1, v1.instance_id == order_models.Order.id)).join((f1, f1.id == v1.field_id))
                                                                              .join((v2, v2.instance_id == order_models.Order.id)).join((f2, f2.id == v2.field_id))
                                                                              .join((rm.TicketwareUser, rm.TicketwareUser.id == v2.value))
                                                                              .filter((_Value.value == prog_id) &
                                                                                      (_Field.name == 'prog_id') &
                                                                                      (f1.name == 'pay_method') &
                                                                                      (f2.name == 'user_id') &
                                                                                      (order_models.Order.created > last_z))
                                                                              .order_by(order_models.Order.created)
                                                                              .all())
                                                                      
                                                                    • +11
                                                                      >Я не люблю Django. Я не люблю Django ORM, Django templates, Django forms и еще множество вещей в Django.

                                                                      Зачем же автор тогда пользуется этим инструментом? Странный человек.

                                                                      В мире python много хороших инструментов — темплейт-энжины, orm-инструменты, микрофреймворки и т.д.
                                                                      И «джанго-гайс» думаю прекрасно знают о их существовании. Но это же совсем не означает что разработчики джанго должны их использовать.

                                                                      Они сделали свою реализацию ORM — и сделали достаточно неплохо, простой и понятный, подходящий для многих основных задач. Не думаю что они отрицают крутизну sqla, но это совсем не означает что они должны были его использовать в джанго. И называть их слепыми — как то неблагодарно, не под пыткой же вас заставляют работать с джанго.

                                                                      Лично мне ORM нравится — я понимаю что он может, что нет. Для большинства моих задач он подходит. Для критичных и сложных случаев — использую raw-запросы, по моему это оптимально. Мне кажется я не один такой — это и есть подбор инструмента по задачам. И джанго позволяет это сделать.

                                                                      • 0
                                                                        Читаем статью:

                                                                        > И в некоторых Django проектах возникает необходимость в сложных запросах, на которые стандартный
                                                                        > ORM неспособен. Условно предположим, что в момент создания проекта считалось, что Django ORM вполне хватит.

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

                                                                          перефразируя известную фразу — что хорошо с «хабраэкспертом», так это то, что «хабраэксперт» это всегда не ты.
                                                                          • 0
                                                                            Ну блин. Статья о том, как ничего не меняя заюзать мощь SQLA в старом проекте. Что тут сложного то? Ничего не надо выкидывать, ничего не надо переделывать. Просто вместо костылей Dajngo ORM используем SQLA.
                                                                            • +1
                                                                              вроде никто изначально не спорил чтонельзя можно. на стековерфлоу эта тема обсуждалась года 2 назад, съели и переварили.

                                                                              интересна была именно мотивация — зачем.

                                                                              При очевидных недостатках джанги правило парето она соблюдает, если вы попали в оставшиеся 20, то, вероятно, джанга не для вас.

                                                                              Вы в начале заметили, что джангу выбрали до вас, ну вот окружающим ( в частности мне) было интерсно в чем проблема и критерии ее оценки.

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

                                                                              таково мое восприятие.
                                                                              • +1
                                                                                Мое восприятие сильно отличается от вашего, что впрочем с точки зрения философии вполне себе адекватно.
                                                                                Зачем — трудозатраты на написание этой библиотеки были сильно ниже, чем переписка всего проекта ради его десятой части.
                                                                            • 0
                                                                              И тыкать незнакомым людям моветон.
                                                                              • 0
                                                                                крайне удивительно это слушать от человека, который незадумываясь хамил куче незнакомых людей :)
                                                                                • 0
                                                                                  Где же я хамил? Я рассказываю людям о моем восприятии их комментариев, используя исключительно уважительную форму «вы». Проверьте везде, и попробуйте найти хоть одно место, где я скатился на тыкание.
                                                                            • +3
                                                                              я прочитал статью.

                                                                              Никто не спорит что sqla можно использовать в джанго.
                                                                              Вопрос — настолько ли это лучше, насколько утверждаете вы.

                                                                              Например, я создал нужные мне модели и использую тесно завязанный с ними ORM. С помощью этого набора я быстро решил 90% поставленных задач. Допустим осталось еще 10%, которые ORM сделать не может (например, нужна производительность, сложный-сложный джойн или что-то еще).
                                                                              Тут вы предлагаете использовать sqla и использовать синтаксис вроде этого:

                                                                              items = (GuestListEntry.query(GuestListEntryDispatch, EticketDownloadHistory)
                                                                              .outerjoin(GuestListEntryDispatch)
                                                                              .join((Order, (Order.client_id == GuestListEntry.id) &
                                                                              (Order.is_guest == True)))
                                                                              .outerjoin(EticketDownloadHistory)
                                                                              .filter(GuestListEntry.batch_id == batch.id)
                                                                              .all())


                                                                              вместо того чтобы написать свой raw-селект.

                                                                              В чем же в данном случае преимущество sqla перед селектом? ведь ни то ни другое уже не дадут автоматической привязки к моделям Джанги. А если этого нет, я выберу raw — так по возможностям он все же более надежен и гибок чем sqla.

                                                                              Если вы профессионал sqla и умеете его хорошо готовить, возможно Джанго вам и не нужен. Но ведь это не значит что разработчики джанги слепы, а сам фреймворк — какашка.
                                                                              • +2
                                                                                Отличие SQLAlchemy-вского запроса от raw SQL в первую очередь в том что он отработает на любой поддерживаемой БД (Postgres, SQLite), во вторых, что запрос можно конструировать по частям: эта функция добавит пару WHERE условий, эта что-нить приджойнит, эта добавит новое вычисляемое поле, эта добавит проверку что у юзера есть права на доступ к этому объекту и т.п.
                                                                                • 0
                                                                                  Да, я примерно представил возможности sqla. Я думаю многое из того что вы сказали несложно реализовать в django (и его ORM).

                                                                                  Я уверен что sqla мощнее и гибче чем django ORM, но думаю в подавляющем большинстве случаев нет необходимости заменять на него встроенный ORM.
                                                                                  • 0
                                                                                    Именно. В подавляющем числе случаев не надо SQLA тащить. Я изо всех сил всегда стараюсь за ОРМ не выпрыгивать. Так проект сопровождать легче.
                                                                                    Но бывает иногда, что лучше взять SQLA, чем городить костыли.
                                                                                • –1
                                                                                  Ну насчет аспектов джанго можно поспорить. Приезжайте в октябре на pyconua — обсудим предметно, перемоем все косточки Django и всем остальным проектам.
                                                                                  А так да — я считаю, что джанго какашка, и делать на ней новый проект не стоит.

                                                                                  Про маппинг — можно было бы замаппить таблицы SQLA прямо на модели джанго, мой знакомый разработчик так и делал. Я решил не идти этим путем, потому что возможны проблемы от такого подхода. Впрочем есть пространство для размышлений — у него из запроса выплывали джанго модели, что возможно удобно. Просто в том куске, над которым думал я, модели собственно были не нужны. А потому aldjemy и не выкидывает джанго модели.
                                                                                  • 0
                                                                                    >>>я считаю, что джанго какашка, и делать на ней новый проект не стоит

                                                                                    Чтож, это ваше мнение — у меня нет причин с вами это обсуждать :)

                                                                                    По моему, если возникла необходимость прикручивать к джанге sqla — то возможно стоило использовать пайлонс либо какой-нибудь из множества других замечательных фреймворков, из коробки поддерживающих и ориентированных на sqla.
                                                                                    • 0
                                                                                      *facepalm* постановка задачи обратная.
                                                                                      • 0
                                                                                        что за постановка задачи
                                                                                        • 0
                                                                                          Уже есть проект, в нем хренова тонна строк кода, и он на джанго. Переписать?
                                                                                          • 0
                                                                                            Я не могу ответить вам ни да ни нет, не зная что конкретно вы не стали реализовывать на django ORM + raw. Если вы приведете примеры из реального проекта — тогда думаю мы все сможем оценить масштабы озвученной проблемы )

                                                                                            Если серьезно — может есть возможность описать\выложить те задачи которые вы решили не делать на django orm? было бы интересно многим я думаю.
                                                                                            • –1
                                                                                              Я и без вас их могу оценить прекрасно. Более того, я это сделал еще до первой строчки aldjemy, и пару разу перепроверил, что джанго орм мне точно ничем не поможет. И raw sql тоже.

                                                                                              Выкладывать задачи не буду. Можно удовлетворить свой интерес за разработкой своего проекта. А проекты с тонной кода как бы не для общего обозрения обычно, и с NDA.
                                                                                              • 0
                                                                                                грубый вы) я знаю что вы и без меня можете, как и я без вас, и многие другие на этом сайте.