Подключение к базе данных

Как сделать миграции?

Миграция выполняется главным образом с помощью трех команд, которые заключаются в следующем:

• 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

Вдобавок к использованию нулевой миграции вы можете использовать любую арбитражную миграцию, и, если миграция была в прошлом, то база данных вернется к состоянию этой миграции, или откатится вперед, если мирация еще не запускалась.