I have an issue with column name on Django migrations after making manual migration

Using Django Using the ORM
21

So, how to bypass that? I would’ve use Django native methods, but it doesn’t support USING keyword, and I can’t make reverse SQL with that method either, so how to solve this?

22

I got this idea, you may have to test it before using in production.

1) method

Frist run makemigrations.

Then open generated migration file in IDE.

Then IgnoreMigration,

    from django.db import migrations
    import django_migration_linter as linter
    
    class Migration(migrations.Migration):
        operations = [
            linter.IgnoreMigration(),
        ]

2) method

Empty Migration: Create an empty migration, apply it, then replace it with the actual migration.


    python manage.py makemigrations --empty myapp
    python manage.py migrate myapp
23

Are you able to revert your code back to how it was before you started these changes? I’m not clear what’s already deployed to production or not.

Because there’s probably a better way to do this if you’re able to start over. i.e., don’t manually make changes to the database, only do it using migrations.

24

I can, my migration is revertable and not deployed yet.

But django migrations are very restricted and not support some specific keywords or funcationality that available only on single DB (in my case Postgres), for example.

25

So I would start over. Do all the changes to the structure that you can by altering the Django model and running makemigrations. Avoid using RawSQL as much as possible.

Something like:

  1. Add new column to the model. Make migration and migrate.
  2. Create a data migration to populate the new column with data (by updating/creating Django objects, not directly using sql). Migrate.
  3. Remove the old column. Make migration and migrate.
26

I don’t really like approach or adding and removing columns, because that will put column to an end when it can be modified in place. But I’m also not particularly know the intricates of this methods. I usually work with different library, it just that I’ve been put on this project that was already make in Django and need some refactoring. This is the first Django project for me.

27

Sorry, I don’t understand what you mean by this.

You want to change some data from a string, to a foreign key. The easiest way is to create a new fk column, populate it with data, then delete the old column.

1 Like
28

When new column is added to a table it always added to it’s end,
e.g. if table look before: id, name, status, description, date, user, doing your way will restructure it to id, name, description, date, user, status_id

29

Also I’m not sure how to make that action within migration using django methods.

30

Why does that matter?

What action?

31

Oups, I misspelled, I wanted to say “within one migration”, theoretically I can make two columns as existing status and new as status_id of foreign type, but I’m not sure if Django will name it properly as status_id or will add another id to it’s end status_id_id.

And speaking of columns, there is one issue, that I put into spoiler in first message regarding my exact case, but it may be a typing typo from linter (not sure), it doesn’t see db_default on Foreign Keys and even in migration file it erroring out about it.

image
image1263×113 14.2 KB

32

So do this:

  1. Add new column, new_status, to the model. Make migration and migrate.
  2. Create a data migration to populate the new column with data (by updating/creating Django objects, not directly using sql). Migrate.
  3. Remove the old column. Make migration and migrate.
  4. Rename new_status to status. Make migration and migrate.

I don’t know about that error. I would try this first, with the only bit of migration you write yourself being the code in step 2.