Step 5 (S-44797)

From Stepik Wiki
Jump to: navigation, search

Step on Stepik: https://stepik.org/lesson/14830/step/5

Step 5 (S-44797) 1.png

[00:00 - 00:18] итак мы завершаем обсуждения подсистема джанге что есть в библиотеке доступа к данным рр и нам осталось поговорить про 1 важную вещь и немножко best practice


[00:18 - 00:36] 1 важная вещь это миграции что такое миграция а не драться то процесс изменение структуры базы либо структурной модели а дело в том что приложение приложение они как правило существует долго и развиваются


[00:36 - 00:51] то есть некоторое время на разработку deployed приложение оно работает а потом появляются дополнительные требования со стороны заказчика либо вы хотите сделать а новую версию добавить функционал


[00:51 - 01:10] но вы не можете просто так изменить вашу модель тогда разойдется структура модели и таблиц в базе данных и все перестают работать то есть при каждом изменении модели если ваше приложение уже запущено работает в продакшне вам нужно производить


[01:10 - 01:26] соответствующие изменения в базе данных а для этого используется механизм миграций а существуют разные подходы к решению этой проблемы в джанге начиная с версии 1 7


Step 5 (S-44797) 2.png

[01:26 - 01:42] а есть встроенная система миграций до 1 и 7 а можно использовать отдельный специальный тебя есть такая является касался


[01:42 - 01:59] мы будем рассматривать стандарт миграции а в джанге миграция представляет из себя а отдельные файлы внутри каждого файла находится класс миграции


[01:59 - 02:17] а джанге миграция описывают не структуру таблиц а структуру модели причем они версионировать а таким образом джанго может автоматически отслеживать разницу между вашими моделями


Step 5 (S-44797) 3.png

[02:17 - 02:35] и а тина теми моделями которые сейчас описано в воде и теми моделями которые конструирования по всем миграцией миграцией джанги разделены по приложение а если у вас есть директория с приложением и в ней есть директория


[02:35 - 02:51] grey шанс такие моменты игры считается что данное приложение работает с поддержкой django миграции а если этой директории нет значит


[02:51 - 03:07] приложение старое и django миграцией не поддерживает а в чем + django миграция в том что они автоматически есть 2 команды которые следует знать это мы крышам


[03:07 - 03:22] ну вызываются ими great что делает команда команда мы игры шанс а с 1 стороны она загружает ваши модели текущей модели в памяти то есть моделям знают post


[03:22 - 03:39] python класса не загружаются в память с другой стороны а она берется первоначально точку отсчета и применяют последовательно все миграции таким образом а применив все миграции в памяти она получает а


[03:39 - 03:57] те модели которые были на предыдущем шаге а затем сравнивая те модели которые есть в восходе и те которые были построены по всем миграция а джанго генерируют новую миграцию которая собственно говоря


[03:57 - 04:12] а приводят проводят соответствующие изменения соответственно когда вы делаете моих мегрэ шанс джанго дописывает файлы вот в эту директорию то есть появляются новые миграции


[04:12 - 04:31] в большинстве случаев это команда отрабатывает без если вопрос создается новый файл следующая команда manage t a great а данная команда применяют миграции которые не были еще применены


[04:31 - 04:49] к базе данных а в базе хранится список примененных миграции поэтому те которые не были применены они меняются и структуру базы соответственным образом меняется когда вы например устанавливаете устанавливаете какой то


[04:49 - 05:06] новое приложение с поддержкой миграции вы вместо 70 d может запустить не греет и еще важнее когда вы обновляете существующие приложения в нем появились новые модели вам нужно запустить открыть а в чем


[05:06 - 05:24] плюсы и минусы а плюсы во 1 это легко и удобно то смех на крышу с потом играет а + поддержка разных баз данных то есть если вы делаете приложение для посольства предполагать что вы будете кому то отдавать предложение


[05:24 - 05:42] вам нужно побеспокоиться чтоб оно работало на всевозможных базах данных обеспечивают это уровень абстракции о миграции а в классе миграция есть 2 операции прямая миграции обратно то есть в принципе миграции обеспечит вам версионирования


[05:42 - 05:58] вы можете накатить эти миграции а потом частичных откатить а тут нужно помнить про потерю данных то есть если у вас а добавила с какой то в поле в таблице в нем помещались какие то данные то вы откатываете миграцию это поле удалится


[05:58 - 06:13] данные теряются то есть это такая операция не идеально а миграцией есть 1 проблема когда речь идет про


[06:13 - 06:30] какой то хитрый достаточно большой проект миграции могут быть удобная либо недостаточно выразительным то есть на практике вместе с изменениями в базе может потребоваться сделать какие то сложные манипуляции а


[06:30 - 06:49] с миграциями не всегда получается сделать поэтому иногда удобнее использовать свои миграции не встроенная с вами для того чтобы использовать а своей миграции вам нужно гарантировать что а в ваших приложениях нету директориями gracious


[06:49 - 07:07] о своей миграции а оформляются просто в виде отдельных скриптов а это уже не относится к фреймворку django это просто такая практика разработки например если у вас есть проект вы можете создать в нем отдельную директорию грешен


Step 5 (S-44797) 4.png

[07:07 - 07:22] и туда складывать скрипты а вот пример как выглядит 1 из таких скриптов а в начале скрипта импортируются а


[07:22 - 07:39] состав и junk это для того чтобы поднять инфраструктуру окружения и импортируется а модуль settings котором находятся ваши настройки запускается с товаром который


[07:39 - 07:57] полностью настраивать окружение джанге делает необходимые содержат соединения с базой данных кошаками и тому подобное после а после этой строчки вы можете использовать все функции джо как том например получить соединения получить курсор и выполнить некоторые запрос


[07:57 - 08:13] а здесь мы видим как здесь нас есть довольно большой служебный вход в самом начале вот а


[08:13 - 08:30] именно по этой причине для всех прочих случаях рекомендуется использовать менеджмент команды для написания таких скриптов эмиграции в этом нет проблемы в этом дополнительном коде потому что миграция еще просто копирует 1 из другой проблем особых не возникает


[08:30 - 08:50] а в чем недостаток таких миграцией а + в том что они гибкие позволяют делать именно все что вы захотите - в том что они завязаны на определенную базу данных поскольку пишется с розыске и у них нет обратных миграций


[08:50 - 09:05] но на практике обратной миграции нужны а по поводу именования миграции файлов а хорошей практикой является начинать


[09:05 - 09:21] имя файла миграции с даты а таким образом вы гарантируете что вас не будет пересечения ну то есть очень маловероятно что вы создадите 2 миграции с одинаковым именем в 1 день а во 2 что тоже важно


[09:21 - 09:38] у вас появится возможность отслеживать какие миграции уже а были применены какие нет то есть важно полезно упорядочивалось миграции ну и желательно писать какой то а описание того что это миграция делает


[09:38 - 09:58] вот это вполне рабочая схема для использования своих программ итак а в завершении обсуждения django модели хотелось бы еще раз вернуться к 1 важной вещи в разработке


Step 5 (S-44797) 5.png

[09:58 - 10:13] а есть 1 zir анти анти паттерн это плохая практика разработке плохой пример называется контроллер


Step 5 (S-44797) 6.png

[10:13 - 10:28] а сказали что там есть контроля то чем мы говорили что ра ответственность контроллера заключается в том чтобы работать с протоколом http то есть все что специфично для протокола http должно быть вынесено в контроллеров


[10:28 - 10:45] а в остальном контроллер занимается только вызовам методов модели и представления то есть контроллер то место где идет связка уже существующей логики типичная проблема когда в контроллере пишется логика


[10:45 - 11:00] а вот этот подход называется ну это так называется контроллер когда вся бизнес логика приложения впишется в случае с джангой во вьюшках а это решение


[11:00 - 11:15] очень популярна среди новичков просто потому что так удобнее программировать есть проблемы я решаю том месте где кажутся наиболее простых а - в том что этот ход невозможно повторно использовать


[11:15 - 11:33] то есть если вы написали какую то логику по осуществлению действий покупка товара в 1 вьюшки то есть в 1 контроллере вы уже не сможете запустить эту логику скажем и с утилиты командной строки либо


[11:33 - 11:49] а запустить ее через какое то api поэтому всю бизнес логику нужно размещать в моделях если а действие связано с 1 объектом его лучше оформить в виде метода конкретной модели


[11:49 - 12:05] если действие связано а с набором объектов его стоит оформить в виде метода model менеджер если а действие представляет собой какой то процесс которые влекут


[12:05 - 12:24] увлекает множество разных моделей и вы не можете сказать с чем это связано в таких случаях принято создавать классы хелперы ты создается отдельный класс либо модуль здесь не так важно в котором полностью описывается вот этот процесс важно что этот класс а б


[12:24 - 12:42] функция либо модуль а никак не связано с протоколом http то есть там не используется request response там не используется переменная окружения связанный с hd теперь а там идет операция чистые сдал


[12:42 - 12:59] таком случае а этот код вы сможете повторно использовать из другой вьюшки а вот это реально и крайне желательно этому следовать при проектировании ваше приложение а


[12:59 - 13:18] эта практика не стопроцентно нужно понимать в некоторых случаях очевидно что код который вы пишете он является так скажем а время но и не имеет отношения к бизнес модели то есть каждый раз когда вы реализуете какие то требования нужно понимать что


[13:18 - 13:36] а бизнес логики не имеет отношения к модели данных каждый раз когда вы пишете какой то требований нужно понимать что это требование оно расширяет основной бизнес логику либо это просто временное требования и желательно его не помещать


[13:36 - 13:50] основной бизнес логику это приходится такие вопросы решаются интуитивно а ну в общем и целом а рекомендация в том чтобы размещать код как можно больше кода в моделях и в кадр и меньше кода


[13:50 - 13:56] это обеспечит возможность повторного использования вашего хода