Django - Урок 045. Перемещение моделей из одного приложения в другое

Application, Model, Django

Я хотел бы поделиться одним из возможных способов переноса модели данных из одного приложения в другое.

Сразу отмечу, что этот вариант переноса модели данных не на 100% рабочий и может потребоваться дополнительная ручная правка таблиц для корректной установки Content Type. Так как любые подобные модификации чреваты потерей данных для отношений GenericForeignKey.

В моем случае GenericForeignKey не использовался, поэтому такой проблемы не было.

Исходные данные

Предположим, у вас есть старая статья article с моделью Article. Вам нужно создать приложение для блога и перенести модель статьи в это приложение. Использует базу данных PostgreSQL.

Перемещение модели

1. Сделайте резервную копию базы (backup), можете сделать дамп базы и потренироваться на этом дампе на сервере разработки.

2. Переместите код модели Article из article.models.py в blog.models.py . То есть код от старой модели надо убрать.

3. Измените класс Meta в модели Article , чтобы сохранить старое имя таблицы. В данном случае это была article_artilce
   

   class Meta:
         db_table = 'article_article'

4. Изменить все ссылки на модели данных во всем проекте. Это означает изменение всего импорта и ForeignKey .

5. Создайте миграции для обоих приложений в следующем порядке.
   

   python manage.py makemigrations blog
     python manage.py makemigrations article

6. Применить миграцию в поддельном режиме. Это позволит вам добавлять миграции по мере их применения, но никаких изменений вноситься не будет.
   

   python manage.py migrate --fake

   
   На данный момент база данных будет уязвима в том смысле, что она не была создана Тип контента для вашей переданной модели данных.

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

   python manage.py makemigrations blog
     python manage.py migrate

По сути, после этих действий база данных будет работать, а данные будут сохранены. Но вам могут потребоваться дополнительные шаги для настройки базы данных.

Очистка и корректировка базы данных

В зависимости от того, где и как использовалась переданная модель данных. Вам могут понадобиться некоторые действия. Например, корректировка Тип контента для GenericForeignKey .

У меня был самый простой случай — это удаление старого Content Type . Для этого нужно подключиться к базе данных и удалить информацию из всех таблиц, которые могут ссылаться на Content Type старой модели.

Такие таблицы могут быть:

• auth_user_user_permissions
• auth_permission
• django_content_type
• и т.д. другие модели, в которых можно было использовать старые модели до передачи

Я покажу пример старого Content Type из моей базы данных.

Процесс очистки

1. Подключиться к базе данных
   

   sudo -u postgres psql
     \c myprojectdb

2. Давайте посмотрим на таблицу django_content_type, чтобы увидеть, какие идентификаторы имеют устаревший тип контента.
   

   SELECT * FROM django_content_type;

   
   Table output
   

   id |    app_label     |         model         
     ----+------------------+-----------------------
      1 | accounts         | userprofile
      2 | knowledge        | section
      3 | knowledge        | article
      4 | admin            | logentry
      5 | auth             | permission
      6 | auth             | group
      7 | auth             | user
      8 | contenttypes     | contenttype
      9 | sessions         | session

3. Найдя старые id мы можем попробовать их удалить (например 50 и 51)
   

   DELETE FROM django_content_type WHERE id BETWEEN 50 AND 51;

4. Если не получилось, то нужно найти, где используются данные ID. В ошибке будет указано, в каких таблицах они задействованы. В моем случае это были auth_permission и auth_user_user_permissions.
   

   SELECT * FROM auth_permission WHERE content_type_id BETWEEN 50 AND 51;

   
   Вывод таблицы
   

   id  |        name        | content_type_id |    codename    
     -----+--------------------+-----------------+----------------
     154 | Can add chat       |              50 | add_chat
     155 | Can change chat    |              50 | change_chat
     156 | Can delete chat    |              50 | delete_chat
     157 | Can add message    |              51 | add_message
     158 | Can change message |              51 | change_message
     159 | Can delete message |              51 | delete_message
     276 | Can view Chat      |              50 | view_chat
     277 | Can view Message   |              51 | view_message

   
   Далее ищем интересующий id в auth_user_user_permissions
   

   SELECT * FROM auth_user_user_permissions WHERE permission_id=154;

   
   Вывод таблицы
   

   id  | user_id | permission_id
     -----+---------+---------------
     102 |       2 |           154

5. Убираем из таблицы auth_user_user_permissions все разрешения для старого Content Type.
   

   DELETE FROM auth_user_user_permissions WHERE permission_id=154;

6. Убираем разрешение из таблицы auth_permission.
   

   DELETE FROM auth_permission WHERE content_type_id BETWEEN 50 AND 51;

7. Удалить типы контента.
   

   DELETE FROM django_content_type WHERE id BETWEEN 50 AND 51;

Вывод

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

For Django, I recommend Timeweb VDS-server .