Никто не спорит что sqla можно использовать в джанго.
Вопрос — настолько ли это лучше, насколько утверждаете вы.
Например, я создал нужные мне модели и использую тесно завязанный с ними ORM. С помощью этого набора я быстро решил 90% поставленных задач. Допустим осталось еще 10%, которые ORM сделать не может (например, нужна производительность, сложный-сложный джойн или что-то еще).
Тут вы предлагаете использовать sqla и использовать синтаксис вроде этого:
В чем же в данном случае преимущество sqla перед селектом? ведь ни то ни другое уже не дадут автоматической привязки к моделям Джанги. А если этого нет, я выберу raw — так по возможностям он все же более надежен и гибок чем sqla.
Если вы профессионал sqla и умеете его хорошо готовить, возможно Джанго вам и не нужен. Но ведь это не значит что разработчики джанги слепы, а сам фреймворк — какашка.
>Я не люблю Django. Я не люблю Django ORM, Django templates, Django forms и еще множество вещей в Django.
Зачем же автор тогда пользуется этим инструментом? Странный человек.
В мире python много хороших инструментов — темплейт-энжины, orm-инструменты, микрофреймворки и т.д.
И «джанго-гайс» думаю прекрасно знают о их существовании. Но это же совсем не означает что разработчики джанго должны их использовать.
Они сделали свою реализацию ORM — и сделали достаточно неплохо, простой и понятный, подходящий для многих основных задач. Не думаю что они отрицают крутизну sqla, но это совсем не означает что они должны были его использовать в джанго. И называть их слепыми — как то неблагодарно, не под пыткой же вас заставляют работать с джанго.
Лично мне ORM нравится — я понимаю что он может, что нет. Для большинства моих задач он подходит. Для критичных и сложных случаев — использую raw-запросы, по моему это оптимально. Мне кажется я не один такой — это и есть подбор инструмента по задачам. И джанго позволяет это сделать.
"… могут быть воспроизведены в любых средствах массовой информации (газеты, журналы, радиостанции, телеканалы, сайты, информационные интернет-агенства и т. д. ) при ОБЯЗАТЕЛЬНОМ условии – указании имени автора и источника заимствования."
Можно вступить в полемику с автором, но думаю это не имеет смысла.
Главный недостаток, которым по моему обладает автор — предвзятость мышления.
Я считаю главным недостатком консультанта (консультанта, а не шарлатана) — ограниченность кругозора, ограниченность видения и мышления какими то технологиями или чем то еще.
Знаете в чем отличались от вас (меня и других «консультантов») Генри Форд, Таити Оно? Они мыслили свободно, они искали и находили решения для их ситуации. Я думаю, они не были обеспокоены проблемами MRP или JIT — они решали задачи, которые перед ними стояли. Решали имеющимися у них ресурсами.
Предвзятость это плохо. Ведь глупо пытаться есть вилкой суп по причине того, что ложкой невозможно есть спагетти?
А неудачный опыт внедрения — это вина руководителя компании и только его. Глупо — довериться консультантам и ждать чуда. Это как попросить незнакомого вам человека съездить к вам на дачу и посадить помидоры, а осенью поехать собирать урожай.
ERP\MRP\канбан\jit — все эти технологии не помогут руководителю решить тех проблем, которые руководитель еще сам не осознал.
По поводу приведенных примеров — про петровича или ивановича и отгрузки раз в неделю: это все вилами по воде. Для каждой конкретной ситуации нужно конкретное решение. Думаю многие прочитавшие уже вспомнили достаточно много ситуаций из жизни где такой подход «не прокатит».
Никто не спорит что 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 и умеете его хорошо готовить, возможно Джанго вам и не нужен. Но ведь это не значит что разработчики джанги слепы, а сам фреймворк — какашка.
Зачем же автор тогда пользуется этим инструментом? Странный человек.
В мире python много хороших инструментов — темплейт-энжины, orm-инструменты, микрофреймворки и т.д.
И «джанго-гайс» думаю прекрасно знают о их существовании. Но это же совсем не означает что разработчики джанго должны их использовать.
Они сделали свою реализацию ORM — и сделали достаточно неплохо, простой и понятный, подходящий для многих основных задач. Не думаю что они отрицают крутизну sqla, но это совсем не означает что они должны были его использовать в джанго. И называть их слепыми — как то неблагодарно, не под пыткой же вас заставляют работать с джанго.
Лично мне ORM нравится — я понимаю что он может, что нет. Для большинства моих задач он подходит. Для критичных и сложных случаев — использую raw-запросы, по моему это оптимально. Мне кажется я не один такой — это и есть подбор инструмента по задачам. И джанго позволяет это сделать.
:)
Главный недостаток, которым по моему обладает автор — предвзятость мышления.
Я считаю главным недостатком консультанта (консультанта, а не шарлатана) — ограниченность кругозора, ограниченность видения и мышления какими то технологиями или чем то еще.
Знаете в чем отличались от вас (меня и других «консультантов») Генри Форд, Таити Оно? Они мыслили свободно, они искали и находили решения для их ситуации. Я думаю, они не были обеспокоены проблемами MRP или JIT — они решали задачи, которые перед ними стояли. Решали имеющимися у них ресурсами.
Предвзятость это плохо. Ведь глупо пытаться есть вилкой суп по причине того, что ложкой невозможно есть спагетти?
А неудачный опыт внедрения — это вина руководителя компании и только его. Глупо — довериться консультантам и ждать чуда. Это как попросить незнакомого вам человека съездить к вам на дачу и посадить помидоры, а осенью поехать собирать урожай.
ERP\MRP\канбан\jit — все эти технологии не помогут руководителю решить тех проблем, которые руководитель еще сам не осознал.
По поводу приведенных примеров — про петровича или ивановича и отгрузки раз в неделю: это все вилами по воде. Для каждой конкретной ситуации нужно конкретное решение. Думаю многие прочитавшие уже вспомнили достаточно много ситуаций из жизни где такой подход «не прокатит».
Как вы собрали столько фильмов и ссылок — вручную?! Кажется это просто титанический по объему труд.
Просто переведена пока только первая часть.
www.siafoo.net/article/52