Migration messup

[remote ginkgo]

I was going to replace a CharField with a ManyToManyField. I renamed the CharField from foo to foo_old and called the new M2M foo. Django didn't exactly interpret this as transferring the old foo values to foo_old, so that field went full default on me. I changed it so that foo_old became foo again, but when I apply both these migrations to a database, it still turns the foo (CharField) into full default.

I think I need Django to forget about the first migration? But AFAIK the way to go isn't to just delete migrations. I need my CharField's values to not be changed by the migrations.

[exotic umbra]

is there important data in your database?

If not, just drop it entirely, delete those two migration files, and start over

[remote ginkgo]

I'm just copying the live database home to use locally

I need the migration recipe to work on the live database

[exotic umbra]

I am not sure if that's a "yes" or a "no"

[remote ginkgo]

me neither 🙂

[exotic umbra]

I think you said "I have two copies of my django code, each with its own database; one is important, the other isnt"

which is how I used to do it at work

[remote ginkgo]

yes

[exotic umbra]

ok so this is encouraging.

first, throw away those bungled migrations. Then re-copy the database locally.

[remote ginkgo]

so I can just delete these migrations, copy the DB again, makemigrations, migrate?

[exotic umbra]

So now your home setup should exactly match what you've got "in prod"

we're thinking the same thing 🙂

[remote ginkgo]

trying, thanks 🙂

ah yes, that was the solution 👌

[exotic umbra]

"replace a CharField with a ManyToManyField" seems like a strange thing to do. You might need a data migration in addition to the field migrations.

I get the sense that you already suspect you might need to do this migration in more than one step.

[remote ginkgo]

well, the full project is to replace silly freetext with actual hard links

[exotic umbra]

that's fine, as long as you can test; and it looks like you can indeed test

you probably need to write a data migration that uses each charfield to find the relevant row in the foreign table

so, I share your original instinct, to start by making a new field.

[remote ginkgo]

I made a thread for this a while ago, sec

#1204329303467106304 message

[exotic umbra]

• migration 1: make the new field; leave it empty (i.e., null=True)
• migration 2: data migration: populate the new field by writing a little script
• migration 3: optionally, change the new field by removing null=True; also delete the old field

yep we're all in agreement

[remote ginkgo]

yeah my plan is something like that. gonna be miserable to update all tests though

[exotic umbra]

🤷

that's just plain old programming 🙂

Gotta look on the bright side. At least you have tests 🙂

[remote ginkgo]

yeah, idk where I'd be without them. from my uni software testing course, the first lecture was why do we do tests, and the answer was to build confidence in our code

never forgot that

[exotic umbra]

that's maybe the first time I've heard about a uni course teaching something useful 🤣