Вроде легкие вопросы и ответы знаю правильные, но система считает иначе и правильные ответысчитает неправильными. Приходится выполнть по несколько раз. Это я не правильно делаю или тест так составлен? |
Подключение к базе данных
Как сделать миграции?
Миграция выполняется главным образом с помощью трех команд, которые заключаются в следующем:
- makemigrations: Основано на изменениях, внесенных в модели, которая готовит запрос миграции
- migrate: Применяет изменения, подготовленные запросом makemigrations и выводит их статус
- sqlmigrate: Отображает запрос SQL, который подготовил запрос makemigrations.
Таким образом поток для схемы миграции Django может быть сформулирован следующим образом:
python manage.py makemigrations ‘appname’
Это подготовит файл миграции, который будет выглядеть аналогично следующему:
Migrations for 'app_name': 0003_auto.py: - Alter field name on app_name
Затем после того, как файл будет создан, , вы можете проверить структуру каталогов. Вы увидите файл с именем 0003_auto .py в папке миграции; можно применить изменения с помощью следующей команды:
python manage.py migrate appname
Ниже приведены действия, которые необходимо выполнить:
Synchronize non migrated apps: sessions, admin, messages, auth, staticfiles, contenttypes Apply all migrations: appname Synchronizing apps without migrations:
Creating tables... Installing custom SQL... Installing indexes... Installed 0 object(s) from 0 fixture(s) Running migrations: Applying appname.0003_auto... OK
Сообщение ОК говорит о том, что миграция успешно завершилась.
Чтобы добавить больше понимания миграции можно объяснить с помощью следующей схемы:
Существует три отдельных сущности:
- Исходный код
- Миграция файлов
- База данных
Разработчик вносит изменения в исходный код, главным образом в файл models.py и изменяет ранее определенную схему. Например, когда они создают новое поле в соответствии с требованиями бизнеса, или обновляют поле max_length с 50 до 100.
Мы завершим правильную миграцию нашего проекта, чтобы увидеть, как на самом деле работает эта миграция.
Во-первых, мы должны создать начальную миграцию приложения:
python manage.py makemigrations tweets
Migrations for 'tweet': 0001_initial.py: Create model HashTag Create model Tweet Add field tweet to hashtag
Это показывает, что первоначальная миграция был создана.
Давайте теперь изменим нашу модель tweet, которая в настоящее время выглядит следующим образом:
text = models.CharField(max_length=160, null=False, blank=False)
Мы изменим предыдущую модель tweet на:
text = models.CharField(max_length=140, null=False, blank=False)
Так как мы изменили нашу схему, мы теперь должны сделать миграцию для правильной работы приложения.
Из потока миграции мы поняли, что, теперь, мы должны выполнить команду makemigrations, которая будет следующей:
python manage.py makemigrations tweets
Migrations for 'tweets': 0002_auto_20141215_0808.py: Alter field text on tweets
Как вы можете видеть, обнаружено изменение в нашем поле.
Для проверки мы откроем нашу базы данных SQL и проверим текущую схему нашей таблицы tweet.
Соединитесь с MySQL с помощью команды::
mysql -u mysqlusername - pmysqlpassword mytweets
В консоли MySQL напишите:
mysql > desc tweettweet;
Это покажет вам схему таблицы tweet, следующим образом:
| Field | Type | Null | Key | Default | Extra | +---------------+-------------+--------+-------+-------------------+ |userid | int(ll) | NO | MUL| NULL | | |text | varchar(160) | NO | |NULL | | |created_date | datetime | NO | | NULL | | |country | varchar(30) | NO | | NULL | | | is_active | tinyint(l) | NO | | NULL | | +---------------+-------------+--------+-------+-------------------+ 6 rows in set (0.00 sec)
Так как мы еще не применили наши миграции, база данных ясно отображает текст в символьном поле в 160 символов:
text | varchar(160) | NO | | NULL
Мы сделаем именно это, как только применим миграции:
python manage.py migrate tweets
Далее следуют операции, которые нам нужно выполнить:
Apply all migrations: tweet Running migrations: Applying tweet.0002_auto_20141215 0808.. . OK
Наша миграция была успешно применена; давайте проверим то же самое из-под базы данных.
Чтобы выполнить ту же команду desc MySQL в таблице tweet_tweet, используйте следующую команду:
MySQL > desc tweettweet; | Field | Type | Null | Key | Default | Extra | +---------------+-------------+--------+-------+-------------------+ | userid | int(ll) | NO | MUL | NULL | | | text | varchar(140) | NO | | NULL | | | created_date | datetime | NO | | NULL | | | country | varchar(30) | NO | | NULL | | | is_active | tinyint(l) | NO | | NULL | | +---------------+-------------+--------+-------+-------------------+ 6 rows in set (0.00 sec)
И действительно! Наша миграция была успешно применена:
| text | varchar(140) | NO | | NULL | |
Как миграции узнают, что требуется подвергнуть миграции
Django никогда не запускает миграцию более чем один раз на одной и той же базе данных, что означает, что она сохраняет эту информацию. Эта информация управляется таблицей под названием django_migrations, которая создается первый раз, когда запускается приложение Django, и для каждой миграции после этого, вставляется новая строка.
Например, вот как может выглядеть таблица после запуска нашей миграции:
mysql> select * from django_migrations -+ -+ + -+ -+ + id 1 app | + name | applied | + + i tweet 1 0001 initial | 2014-12-15 08:02:34 | 2 tweet -+ 1 0002 -+ _auto_20141215_0808 | 2014-12-15 08:13:19 | +
Предыдущая таблица показывает, что присутствуют две миграции с помеченной информацией, и то, что каждый раз, как вы мигрируете, эти изменения пропустятся, так как уже есь запись в таблице, относящаяся к файлу миграции.
Это означает, что даже если вы измените файл миграции вручную, он будет пропущен.
Это обращает на себя внимание, так как вы не хотите запускать одну и ту же миграцию дважды.
Конечно, если вы действительно хотите запустить одну и ту же миграцию дважды, то вам следует удалить запись таблицы "THIS IS NOT A OFFICIALLY RECOMMENDED WAY" и все будет прекрасно работать.
Продолжая разговор, если вы хотите отменить все миграции для конкретного приложения, вы можете мигрировать в особую миграцию, называемую нулевой.
Например, если вы наберете следующую команду, все ваши миграции для приложения tweet обратятся:
python manage.py migrate tweet zero
Вдобавок к использованию нулевой миграции вы можете использовать любую арбитражную миграцию, и, если миграция была в прошлом, то база данных вернется к состоянию этой миграции, или откатится вперед, если мирация еще не запускалась.