Да нет же. Я про интеграцию — когда нужно, есть путь как прикрутить SQLA в проект, вот и все. А убеждать в пользе SQLA я никого и не собирался. Просто поделился своим решением.
Да не нужно примеров. Когда вам понадобится SQLA, вы об этом точно узнаете. Просто пока она вам не нужна — ну не объяснить. Да, у вас прямые. Это же клево! А у меня уже навороченные и select_related спасать перестал.
Привычка выкинуть при прочтении половину строк сильно подводит вас.
> А вот что хотелось бы узнать у автора, это всерье ли он считает, что
Конечно нет, что видно из текста: Но на самом деле, надо ли использовать SQLA для выборки пользователей в группе? Конечно нет!
Никто не предлагает заменять ORM, я предлагаю решение для сложных случаев.
Я отлично знаю пределы возможностей Django ORM. Ни фига они не покрывают, достаточно шаг влево, и капут. Все эти примочки типа F, annotate и тому подобное, это костыли к изначально кривой идее. И то, что «сами разработчики» знают об этом, не делает SQLA ненужным. Когда уже запрос стал достаточно сложным, надо брать SQLA.
Сказать вам что было видно стартующему проект, для которого была сделана Aldjemy, я не берусь. Но думаю он не рассчитывал на некоторые use-case проекта, которые возникли позже.
В общем «не учите меня жить», будут такие же проблемы возьмете aldjemy и решите.
Я как то уже очень давно читал, почему надписи в гуглокартах хорошо читаются. Рекомендую найти. Одним из моментом была белая окантовка, при использовании которой надписи читаются на любом фоне.
Ну и главное — прибитые к определенным местам подписи это плохо — увеличиваешь, сдвинулся от подписи, и уже черт знает, что там за улица. В вебе и на десктопе еще как-то можно жить, но на мобильнике это очень неудобно.
Нет, ну что вы, Twisted он не для того. Строить на twisted web проект вообще гибло. На Twisted надо писать какой-нибудь хитрый демон который что-то там распихивает из одного сокета в другой, или SIP-прокси с биллингом. В общем что-то сетевое под большой поток пакетов.
К поздней стадии развития проект уже придет с какой-то конкретной технологией. Поэтому пространства для маневра в таких проектах немного. Какие-то революции там за один день не свершаются, если вообще стоят денег.
Для web лично я возьму Flask, sqlalchemy, jinja2. С sqlalchemy SQL вам придется писать, только если вы его запихнете в хранимку на сервере. С jinja2 логика представления останется в шаблонах. Flask гибок, и я не думаю, что упрусь куда-то при его использовании. Хотя тут нужно больше опыта, на данный момент Flask все таки молод. С другой стороны его стиль мне уже хорошо знаком. В родственном Flask фреймворке Svarga я никуда не уткнулся на довольно большом проекте, и многие вещи, с которыми на джанго приходилось бодаться, я там вообще не замечая решал походя. Кстати из Svarga вышла Amalgam, тоже неплохо можно внедрить себе.
В общем в моем личном списке Django не значится как инструмент номер один. Скорее как legacy.
Джанго и есть попытка слепить все в один проект. Синдром NIH, крайне урезанные инструменты, шаг влево вправо и начинаются костыльные кошмарики.
Любой проект стартует ни разу не специфическим. Обычно начинается с того — ну тут пару страничек, тут простенько, ну и пока можно еще немного админкой попользоваться стандартной.
Проблема в том, что любой проект заказчик хочет потом улучшить. В один прекрасный день вы упираетесь в то, что джанга она такая — для простеньких проектов, проект бывает таким в начале своей жизни. Но куда вы потом от нее денетесь? Весь проект перепишете? Заполните ее raw sql вставками? А тесты в sqlite уже пускать не сможете, БД не смените.
Я долго могу каждый пункт разбирать, и пояснять почему сделано криво, и где лучше. Но вообще клуб django-haters он большой, где то были уже материалы в сети с подобным разбором.
Если следовать MVC джанго, то в шаблоны надо передавать готовые куски html-я, чтобы не дай бог какую логику в шаблоны не затянуло. И логика представления ложится ровным слоем в templatetags и во вьюхах.
Шаблоны джанго это первое, что нужно сразу же от нее отрывать. Потом мы переходим к ORM, попадаем в засаду, когда заказчик просит сложный отчетик, отрываем и пользуем sqlalchemy.
Потом мы понимаем, что от джанги собственно ничего не осталось, и можно переходить к использованию Flask например.
А может лучше уж сразу, полностью заменить язык шаблонов в джанго на php? Передавать контекст, обязательно подключить какой-либо акселератор — мы выйдем на новые горизонты!
У джанго совершенно убогие шаблоны, ни тебе доступа к БД, ни сокетов. Поэтому я считаю, что вы молодец. Все эти жалкие попытки в виде haml, jinja2, mako и mint явно были заблуждением.
Кстати, а что по вашему делает select_related? Опять «эксперт»?
> А вот что хотелось бы узнать у автора, это всерье ли он считает, что
Конечно нет, что видно из текста:
Но на самом деле, надо ли использовать SQLA для выборки пользователей в группе? Конечно нет!
Никто не предлагает заменять ORM, я предлагаю решение для сложных случаев.
А вы точно читали статью? Александр, плохо рубить с плеча незнакомый текст, вы хоть ознакомьтесь с ним, чтобы рубить предметно.
Сказать вам что было видно стартующему проект, для которого была сделана Aldjemy, я не берусь. Но думаю он не рассчитывал на некоторые use-case проекта, которые возникли позже.
В общем «не учите меня жить», будут такие же проблемы возьмете aldjemy и решите.
И SQLA инструмент по задаче — есть проблема на старом проекте со сложными запросами — берем SQLA и решаем.
Ну и главное — прибитые к определенным местам подписи это плохо — увеличиваешь, сдвинулся от подписи, и уже черт знает, что там за улица. В вебе и на десктопе еще как-то можно жить, но на мобильнике это очень неудобно.
К поздней стадии развития проект уже придет с какой-то конкретной технологией. Поэтому пространства для маневра в таких проектах немного. Какие-то революции там за один день не свершаются, если вообще стоят денег.
Для web лично я возьму Flask, sqlalchemy, jinja2. С sqlalchemy SQL вам придется писать, только если вы его запихнете в хранимку на сервере. С jinja2 логика представления останется в шаблонах. Flask гибок, и я не думаю, что упрусь куда-то при его использовании. Хотя тут нужно больше опыта, на данный момент Flask все таки молод. С другой стороны его стиль мне уже хорошо знаком. В родственном Flask фреймворке Svarga я никуда не уткнулся на довольно большом проекте, и многие вещи, с которыми на джанго приходилось бодаться, я там вообще не замечая решал походя. Кстати из Svarga вышла Amalgam, тоже неплохо можно внедрить себе.
В общем в моем личном списке Django не значится как инструмент номер один. Скорее как legacy.
Любой проект стартует ни разу не специфическим. Обычно начинается с того — ну тут пару страничек, тут простенько, ну и пока можно еще немного админкой попользоваться стандартной.
Проблема в том, что любой проект заказчик хочет потом улучшить. В один прекрасный день вы упираетесь в то, что джанга она такая — для простеньких проектов, проект бывает таким в начале своей жизни. Но куда вы потом от нее денетесь? Весь проект перепишете? Заполните ее raw sql вставками? А тесты в sqlite уже пускать не сможете, БД не смените.
Я долго могу каждый пункт разбирать, и пояснять почему сделано криво, и где лучше. Но вообще клуб django-haters он большой, где то были уже материалы в сети с подобным разбором.
Шаблоны джанго это первое, что нужно сразу же от нее отрывать. Потом мы переходим к ORM, попадаем в засаду, когда заказчик просит сложный отчетик, отрываем и пользуем sqlalchemy.
Потом мы понимаем, что от джанги собственно ничего не осталось, и можно переходить к использованию Flask например.
Ну а если не получается орм оторвать, то можно дополнить — github.com/Deepwalker/aldjemy
Но топик не о шаблонах, а о крутейшем трололо, которому было не лениво сляпать такое :)
У джанго совершенно убогие шаблоны, ни тебе доступа к БД, ни сокетов. Поэтому я считаю, что вы молодец. Все эти жалкие попытки в виде haml, jinja2, mako и mint явно были заблуждением.