В общем «не учите меня жить», будут такие же проблемы возьмете aldjemy и решите.
Сказать вам что было видно стартующему проект, для которого была сделана Aldjemy, я не берусь. Но думаю он не рассчитывал на некоторые use-case проекта, которые возникли позже.
Я отлично знаю пределы возможностей Django ORM. Ни фига они не покрывают, достаточно шаг влево, и капут. Все эти примочки типа F, annotate и тому подобное, это костыли к изначально кривой идее. И то, что «сами разработчики» знают об этом, не делает SQLA ненужным. Когда уже запрос стал достаточно сложным, надо брать SQLA.
9 сентября 2011 в 01:53
Ну по моему не кто не говорил что django orm идеальна, и сами разработчики говорят что они покрывают самые базовые вещи, а всё что за пределами то используйте пожалуйста сырые запросы sql или что либо иное, при этом orm покрывает 90% всех потребностей. Но есть другая проблема, так называемые ваши ребята не видят не только что за пределами, но и то что есть из коробки, большая часть вопросов решается прочтением документации (есть и сеты и F и т.п), а не криками как всё плохо и бежать искать что либо иное. Вопрос в правильном выборе инструмента, и если изначально видно что будет сложная структура, то это уже другой разговор.
9 сентября 2011 в 01:10
Пример кода, который вы так просите
Из документации: But aldjemy is not positioned as Django ORM drop-in replacement. Its helper for special situations.
1. Django guys это такие ребята, которые упорно не желают видеть недостатков Django. Более того да они даже не в курсе про множество библиотек за пределами этого узкого Dj-мирка.
Стоп, нужно указывать все join-ы явно? Конечно, это же SQLA, и в SQLA запросы строятся с явным указанием всех join-ов и прочего. Но на самом деле, надо ли использовать SQLA для выборки пользователей в группе? Конечно нет! SQLA придет на помощь в тот момент, когда вы будете писать сложный запрос, направленный на оптимизацию, на ускорение генерации страницы и здесь возможность написать именно тот запрос, который вам хотелось, будет благословением.
User.sa.query.join(User.sa.user_groups).join(User.sa.user_groups.property.mapper.class_.group).filter(Group.sa.name=="GROUP_NAME")
Попробуем, запускайте ./manage.py shell_plus и введите:
Для использования вам просто нужно добавить `aldjemy` в конец INSTALLED_APPS, и aldjemy пройдется по всем моделям и добавит к ним аттрибут `sa`.
Какие недостатки при использовании SQLAlchemy? Нужно описать структуру данных для этой библиотеки отдельно, так как SQLAlchemy и Django ORM не совместимы, да и не было такого плана у их создателей. Также вы можете попробовать построить модель данных по структуре из БД. Тоже вариант, но всплывают тонкие моменты, когда собственно БД еще нет. Я пошел по другому пути и построил структуру по джанго моделям в своем проекте Aldjemy.
И в некоторых Django проектах возникает необходимость в сложных запросах, на которые стандартный ORM неспособен. Условно предположим, что в момент создания проекта считалось, что Django ORM вполне хватит. Для решения можно писать чистый SQL или воспользоваться SQLAlchemy. Я за второй подход, так как чистый SQL плохо поддается DRY-фикации.
Что в SQLAlchemy лучше чем в Django ORM? Это главный вопрос, который я слышу от Django guys1, и у меня есть на него ответ SQLAlchemy может выразить любой SQL запрос (ну 80-90%), в отличие от Django ORM, в котором можно выразить только весьма простые вещи.
Я не люблю Django. Я не люблю Django ORM, Django templates, Django forms и еще множество вещей в Django. Но у Django есть определенное преимущество многие используют Django, практически любой python-программист знаком с джанго. Поэтому приходится мириться с недостатками этого фреймворка, но никто не мешает облегчать себе жизнь, используя действительно хорошие python библиотеки, например SQLAlchemy.
9 сентября 2011 в 00:20
SQLAlchemy для Django / Хабрахабр
Комментариев нет:
Отправить комментарий