-
-
Notifications
You must be signed in to change notification settings - Fork 800
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update migrations #224
Update migrations #224
Conversation
Move existing migrations to south_migrations and add new Django-supported migrations in their place.
1 similar comment
1 similar comment
This change makes django-oauth-toolkit work for my Django 1.7 project. 👍 Thanks @dustinfarris! |
Be careful if you are simultaneously upgrading to DOT 0.8 as an extra attribute was added without doing a proper migration. (0656670) You will begin seeing errors, like:
To truly migrate, you will have to:
This will result in a loss of data. I am not sure why the maintainers explicitly chose to forego a migration here. See #219. I can potentially update the new migrations for Django >= 1.7 in this PR to accommodate a smoother transition, but I'd like to know more about why the decision was made to skip this particular migration in the first place. |
Thanks for your work! @dustinfarris |
Without using south migrations, how can we avoid data loss? |
A first stab at aligning migrations with recent versions of Django.
Existing migrations are moved to south_migrations. This means South users will need to be >= 1.0.0 which looks for this directory, or they will have to add to their settings.py:
I have not extensively tested this on existing projects, but it should be enough to get the conversation started.
Also a great blog post here on supporting new Django migrations in third-party apps: http://treyhunner.com/2014/03/migrating-to-django-1-dot-7/
Note: if you need this right now (for instance if Django is blowing up because you have a custom AUTH_USER model that needs to migrate before oauth2_provider, e.g. if you're seeing things like
django.db.utils.ProgrammingError: relation "myapp_user" does not exist
when you run your tests), you can replicate the new migrations folder from my fork into your app as something likemyapp/oauth2_provider_migrations/
and then add to your settings.py:Assuming you've been using oauth2_provider for a while, you will need to fake the migration on your regular db so it doesn't complain about the table already being there in the future: