I changed a lot in my models.py, including deleting a lot of fields, and renaming a couple of classes. schemamigration --auto worked fine, but trying migrate threw a bunch of errors.
All my code is currently in development so I don't mind too much losing the data. So I want South to "unconvert" or "unmanage" an app so I can rebuild all the tables with syncdb again.
Or I could delete all migration list and do schemamigration --initial again.
Yes, just delete the migrations and run schemamigration --initial again. You should do that anyways as normal course before moving to production. If you've already gone to production at least once, don't delete all the migrations -- just the ones you've created in the current development cycle and then run schemamigration --auto to get just one migration instead of the potential multiple ones.
FWIW, to "unconvert" an app using South, you merely delete the "migrations" directory, but in this scenario, there's no need.
UPDATE
It was pointed out that if you have already migrated your app, and you delete all the migrations and generate a single new one, South will complain about migrations still in the database. The actual process you should follow is:
Rollback to the just before the newest migration you created in the current development cycle. For instance, if you were already at 0005 and you created three new migrations for the development work you were doing (now at 0008), you would rollback to 0005. If all of the migrations are new, you rollback to zero:
python manage.py migrate yourapp zero
Delete all of the migrations you're going to merge. In the above example, that would be 0006, 0007, and 0008, or for a new app, everything in the migrations directory but __init__.py.
Generate a new migration to cover the ones you just deleted. If it's a new app, use --initial, or if it was a pre-existing app, use --auto.
python manage.py schemamigration --initial yourapp
Migrate
python manage.py migrate yourapp
Related
I have already had some migration files, and I made some changes in the model and did
python manage.py makemigrations
python manage.py migrate
After that in postgresql table django_migrations there is a row indicating I've applied that migration, let's call this migrationA.
I deleted the new generated migration file (migrationA), modified a small piece in my model and then did
python manage.py makemigrations
python manage.py migrate
This generate migrationB. I was hoping this can do the same as squashing migration files.
Will this kind of flow cause any trouble? I didn't see any trouble now but want to make sure this is a safe way to do things. In addition, is there any way to revert postgresql to the time before I applied migrationA?
Yes, it will cause trouble. All the migrations are stored in the migrations table and just deleting a migration will produce inconsistencies between your actual migrations and what's recorded.
Before deleting a migration and creating a new one, you need to first revert it by running ./manage.py migrate my_app number_previous_migration_name.
I changed a field on a model class (which has no classes point to it, only one foreign key pointing out of it). Somehow, this stuffed up my migrations and it keeps saying "django.db.migrations.graph.NodeNotFoundError:" looking for migration files that do not exist.
I accidentally deleted several files in my 'migrations' folder.
My database contains a lot of data, and I do not want to break it.
Will I lose any data if I:
Remove the table that caused the problem in the first place (psql, \d, DROP TABLE tablename)
delete all my migration files
Re run the migration from the start?
./manage.py makemigrations
./manage.py migrate
Can anyone recommend another way of fixing this?
Here is the traceback:
http://dpaste.com/0Y1YDXS
Aren't you using git so that you can get your migration files back? If not, install and use it, starting now
I would suggest:
make a backup/dump of your database first, in case something goes wrong
Delete all migrations
Empty migration table in psql
call makemigrations
call migrate --fake-initial
Empty the django_migrations table:
delete from django_migrations;
Remove all the files in migrations folders in each and every app of your project.
Reset the migrations for the "built-in" apps:
python manage.py migrate --fake
Create initial migrations for each and every app:
python manage.py makemigrations your_app_name
Final step is to create fake initial migrations:
python manage.py migrate --fake-initial
See here https://micropyramid.com/blog/how-to-create-initial-django-migrations-for-existing-schema/
I have an app that currently has 35 south migrations. These take a while to go through when setting up a new deployment (we create new deployments often), and the app is continually evolving--adding more migrations. Additionally, the migrations include some potentially complex data migrations and a few custom migrations that break SQLite3 (not a huge problem right now since everything is on Postgres, but its nice to be able to set up a quick test environment), and generally just more things that can go wrong.
All of our deployments and developers are up to date, and I'd like to clear out all of the app's migrations and create a single initial migration (0001) that captures the current state of the app, and then go forward with new migrations from there. I did this a few years ago with a different app, and it worked out nicely, but I've since forgotten what the process was and lost track of the blog post that explained how to do it. Can anyone break down this process for me?
I figured this out (wasn't too bad). To set up the migration reset, I do the following:
rm <app-dir>/migrations/*
python manage.py schemamigration <app-name> --initial
python manage.py migrate <app-name> 0001 --fake --delete-ghost-migrations
I commit the changes to the repository, and then for each deployment of the code elsewhere, run:
python manage.py migrate <app-name> 0001 --fake --delete-ghost-migrations
Make sure you don't add anything new between the time you last migrated everywhere else and you reset things or the new 0001 migration won't match up with the schema!
Caveats: See guettli's comment (and my responses)
I have just started using South (finally) and it is really a great tool. I started a project and did a few initial migrations to get the feel of South. I have now just git cloned this project onto a new machine. In do not have the database data, as there was no data enter yet.
My question is what are the steps to rebuild the database?
I have tried:
./manage.py schemamigration <myapp> --auto
and:
./manage.py migrate <myapp>
But it says nothing seems to have changed.
Do I also need to run an initial syncdb? Will the South migration history be intact?
Any help much appreciated.
Yes, you need to run syncdb initially to load the south migration history table
Edit your settings.py and put ‘south’ into INSTALLED_APPS (assuming you’ve installed it to the right place)
Run ./manage.py syncdb to load the South table into the database. Note that syncdb looks different now - South modifies it.
Run ./manage.py convert_to_south myapp - South will automatically make and pretend to apply your first migration.
See Converting an App
I am using South to manage schema and data migrations on my development and production environments. As such I keep my migrations in my git repository so changes I make in development are properly migrated in production.
The apps and projects I am developing are currently private and only developed by me. At some point, I would like to publish/distribute my apps. I am assuming that at that point, I will have a "final" schema and therefor won't "need" South. Since these apps haven't been distributed before (except on my environments), the public version won't need the migrations that I used while developing the apps.
I have a two parter question:
Is it good (or acceptable) to remove or at least "clean up" the migrations based on my assumptions?
What's the best way of doing so? I imagine keeping a branch for the public/distributed base could work, but I'm fairly new to git, so I don't know what my options are.
Thanks,
This is a common point of confusion for people dealing with South and version control. You should, of course, commit migrations with your project, as others will need to run the same migrations themselves. However, you should clean up your migrations before committing them, which is actually deceptively easy.
If it's a brand new app or a brand new project in general:
Rollback the app to "zero":
python manage.py migrate myapp zero
Delete all migrations for the app (Everything in the "migrations" directory except __init__.py).
Generate a new initial migration:
python manage.py schemamigration --initial myapp
If it's an existing app, then the process is largely the same, but you're only going to rollback to just before the first new migration your created. And, then you will simply generate a new auto migration instead of an initial migration. For example, if the app was already at migration 0005 and you create migrations 0006, 0007, and 0008:
Rollback to just before the first migration you created (0006):
python manage.py migrate myapp 0005
Delete all new migrations you created (0006, 0007, and 0008)
Generate a new auto migration:
python manage.py schemamigration --auto myapp
Either way, you'll end up with just one file encapsulating all of your changes instead of multiple files. Then, you commit this to your source control.