Django - Tutorial 045. How to move model from one application to another

Application, Model, Django

I would like to share one of the possible way for moving the data model from one application to another.

Immediately, I note that this version of the data model transfer is not 100% working and you may need additional manual editing of the tables to correctly set the Content Type. Since any such modifications are fraught with data loss for GenericForeignKey relationships.

In my case, GenericForeignKey was not used, so there was no such problem.

Initial data

Suppose you have an old article article that has the Article model. You need to create a blog application and transfer the Article model to this application. Uses PostgreSQL database.

Moving a model

1. Make a backup copy of the database (backup), you can make a database dump and practice on this dump on the development server.

2. Move the model code Article from article.models.py to blog.models.py . That is, the code from the old model must be removed.

3. Edit the Meta class in the Article model to keep the old table name. In this case, it was article_artilce
   

   class Meta:
         db_table = 'article_article'

4. Change all references to data models in the whole project. This means change all imports and ForeignKey .

5. Create migrations for both applications in the following order.
   

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

6. Apply migration in fake mode. This will allow you to add migrations as applied, but no changes will be made.
   

   python manage.py migrate --fake

   
   At the moment, the database will be vulnerable in that it was not created Content Type for your transferred data model.

7. This can be corrected by the following actions. Now we need to change the name of the table, and this can be done by removing db_table from the data model and creating and applying a new migration to the new application. Content Type will be created automatically when migration is applied.
   

   python manage.py makemigrations blog
     python manage.py migrate

In essence, after these actions, the database will be working, and the data will be saved. But you may need additional steps to adjust the database.

Database cleanup and adjustment

Depending on where and how the transferred data model was used. You may need some actions. For example, the adjustment Content Type for GenericForeignKey .

I had the simplest case - this is deleting the old Content Type . To do this, you need to connect to the database and delete information from all tables that can refer to the Content Type of the old model.

Such tables can be:

• auth_user_user_permissions
• auth_permission
• django_content_type
• etc. other models in which the old models could be used before the transfer

I will show the example of the old Content Type from my database.

Cleaning process

1. Connect to the database
   

   sudo -u postgres psql
     \c myprojectdb

2. Let's look at the django_content_type table to see which id's have obsolete 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. Having found old id we can try to delete them (For example 50 and 51)
   

   DELETE FROM django_content_type WHERE id BETWEEN 50 AND 51;

4. If it did not work out, then you need to find where the ID data is used. The error will indicate in which tables they are involved. In my case, these were auth_permission and auth_user_user_permissions.
   

   SELECT * FROM auth_permission WHERE content_type_id BETWEEN 50 AND 51;

   
   Table output
   

   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

   
   Next, we are looking for interesting id in auth_user_user_permissions
   

   SELECT * FROM auth_user_user_permissions WHERE permission_id=154;

   
   Table output
   

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

5. We remove from the table auth_user_user_permissions all permission for the old Content Type.
   

   DELETE FROM auth_user_user_permissions WHERE permission_id=154;

6. We remove the permission from the auth_permission table.
   

   DELETE FROM auth_permission WHERE content_type_id BETWEEN 50 AND 51;

7. Remove Content Types.
   

   DELETE FROM django_content_type WHERE id BETWEEN 50 AND 51;

Conclusion

In this way, you can move the data model of interest from one application to another, and you can also clean up the database from outdated content. However, it is necessary to work very carefully with the database in order not to violate its integrity.

For Django, I recommend Timeweb VDS-server .