Комментарии 13
Django берет всю головную боль, связанную с проблемами SQL на себя — вам даже не надо знать SQL, чтобы пользоваться Django, от вас нужен только python — Django сам сформирует SQL команды для создания таблиц, поиска и записи данных в таблицы и все это будет безопасно.
Это до тех пор пока не начнутся проблемы и вы не взглянете на тот кошмар который джанговский ORM генерирует в виде SQL, если у вас в модели есть больше чем пара связей… а всякие prefetch и related_prefetch при бездумном использовании запросто выжрут пару гигабайт памяти на, казалось бы, простом запросе.
я к тому что именно джанговский орм научил меня всегда смотреть sql который он генерирует… и иногда писать на чистом sql в обход orm — потому что код в orm, в некоторых случаях, получается гораааздо сложнее и трудночитаемей…
Тут главное знать меру. Работал как-то я над проектом, в котором недавно ушедший lead dev очень любил raw sql и считал что orm тормозит. Код пестрил raw sql вставками и QuerySet.values(). Итого встроенное кэширование не работало, а для внесения даже небольших изменений требовалось изменять достаточно много кода.
В результате — откат "оптимизаций" и использование преимущественно ORM + prefetch related.
В результате — откат «оптимизаций» и использование преимущественно ORM + prefetch related.
Да, только вы отлично знаете как правильно их откатить и грамотно затюнить ORM, а текст в оригинале звучит как «вам даже не надо знать SQL, чтобы пользоваться Django»
тут как раз его надо ооочень хорошо это знать, чтобы пользоватся django :)
И вы наверно имели ввиду prefetch_related? Если так то этот метод не генерирует sql, точнее генерирует но в отдельных запросах. В отличие от select_related.
В django ORM много механизмов оптимизации запросов и только исчерпав их все следует переходить к написанию raw
В итоге сделал себе модуль поверх pymysql/mysql.connector с основными функциями, и с небольшими изменениями тягаю его во все проекты.
В django нет «классовых видов». Во первых, мне кажется более привычным называть view по русски как кальку с англ. т.е «вьюхи». Во вторых, все вьюхи всегда функции, которые на вход принимают request и набор позиционных и именнованных аргументов из url, если они есть. То что вы называете «классовыми видами» на самом деле class based view — вьюхи основанные на классах. В этих классах есть спец метод as_view, который и генерирует нужную функцию на основе класса. Именно результат этого метода мы и используем в urlconf.
</зануда мод>
Но это просто маленькое уточнение. На начальном этапе изучения это не так важно. Статья думаю полезна для новичков.
Я прекрасно помню, как я пытался понять, как работает Django. Мне не хватало общей картины, на которую уже можно нанизывать понимание того, как работают отдельные кусочки (то, что вы описываете в статье — модели, вьюхи, шаблоны).
Я бы посоветовал вам добавить в начале статьи теорию о том, зачем вообще нужны все эти Model-View-Controller, обьяснить общими словами, как MVC структура имплементирована в Django (и куда делся контроллер), добавить cхему движения данных, например вот эту (в интернете можно найти и более детальные схемы, но для новичков данная картинка в самый раз):
детально по шагам разобрать цепочку:
Клиент > Запрос > web server > wsgi > формирование request > middleware > корневой urls > app.urls > app.views > context processors > template > response > wsgi > web server > Клиент
Запросов к БД у вас может и вовсе не быть, либо они могут быть раскиданы по данной цепочке (к примеру вo views, context proccessors или middleware).
Что бы я хотел знать когда начинал изучать Django? — очень общий взгляд