«Чуваки» заменить на «эксперты которые не в курсе что такое SQLAlechmy и считают что автор должен им это пояснить». А я не считаю, что мне нужно вам это пояснять, для этого есть документация, ссылка на которую есть в этом топике.
Тем не менее спасибо Александру за примеры.
У меня есть пример, но он очень большой, могу дать маленький кусочек.
Если оно вам поможет, пожалуйста. Если учесть, что это одна из 10 составляющих запроса, то как это выразить на Django ORM я вообще не знаю. Оно там в итоге еще и джойнится.
Это не агрессия, это экспрессия, тёма-стиль изложения. Цель ввести читателя в состояние сильного возмущения, чтобы он бросил читать статью после первых двух строк, и потом измываться над ним за это в комментах. Жаль только карма страдает так сильно, что на следующую статью уже может и не хватить :D
«MongoDB is web scale».
Каждый видит, то что хочет, но зачем? Ну вот вы узнали о том, что не SQL единым, и теперь ищете тот самый гвоздь, это нормально, мы все так делаем. Но в статье то явно упоминается, что в Django просто нельзя достаточно хорошо контролировать конечный SQL, оттого и нужно иногда инструмент помощнее.
Эксперт-нечитаютопики, я этот пример сам опустил в той самой статье, которую вы не читали. Сравнение Django ORM и SQLAlchemy проведите для себя сами, мне это ненужно. Вам нужно, вы и делайте себе сравнительный анализ. Когда я решу написать статью «почему джанго орм сливает sqla», я ее так и озаглавлю.
> И в некоторых Django проектах возникает необходимость в сложных запросах, на которые стандартный
> ORM неспособен. Условно предположим, что в момент создания проекта считалось, что Django ORM вполне хватит.
Мне кажется, что данная строка отвечает на вашу эскападу полностью. Вопрос, почему вы не прочитали статью, оставим за кадром, селяви и хаброэксперты на марше.
Да ну тут как почитаешь «экспертов» в комментариях, которые SQLAlchemy в глаза не видели и требуют от меня доказать что оно лучше, так пожалуй коброй станешь.
Да, вы пропустили прочесть статью. Статья о том, как ничего не править в проекте, а взять и нафигачить запрос на SQLA без головной боли и без переопределения моделей. Такой вот финт для застарелых проектов, которые переписывать слишком долго.
Это не такой уж франкенштейн, вполне рабочее решение. Генерировать ли модель данных по Django моделям, или брать какую-то обертку для этих целей — такая уж ли это большая разница?
habrahabr.ru/blogs/python/128052/#comment_4231276
Тем не менее спасибо Александру за примеры.
У меня есть пример, но он очень большой, могу дать маленький кусочек.
Если оно вам поможет, пожалуйста. Если учесть, что это одна из 10 составляющих запроса, то как это выразить на Django ORM я вообще не знаю. Оно там в итоге еще и джойнится.
А вот рассуждать об уровнях, когда вы сами только что сказали, что SQLA в упор не знаете, как то наивно, нет?
Каждый видит, то что хочет, но зачем? Ну вот вы узнали о том, что не SQL единым, и теперь ищете тот самый гвоздь, это нормально, мы все так делаем. Но в статье то явно упоминается, что в Django просто нельзя достаточно хорошо контролировать конечный SQL, оттого и нужно иногда инструмент помощнее.
> И в некоторых Django проектах возникает необходимость в сложных запросах, на которые стандартный
> ORM неспособен. Условно предположим, что в момент создания проекта считалось, что Django ORM вполне хватит.
Мне кажется, что данная строка отвечает на вашу эскападу полностью. Вопрос, почему вы не прочитали статью, оставим за кадром, селяви и хаброэксперты на марше.