Django 1.8 migrations

[AlexHill]

In Django 1.8 CurrentSiteManager has the new use_in_migrations flag set to True. The purpose of the flag is so the correct default manager can be used in RunPython operations, etc.

This means makemigrations generates a migration to explicitly set the manager on every model that uses it. The alternative is just to turn it off, which is what I've done in the first commit here.

I've also added a migration for Django 1.8's longer emailfield. Should that be wrapped in a version check?

[stephenmcd]

Thanks a lot Alex!

As I can best tell the version check shouldn't be needed since if the migration is run against 1.7, all that will happen is that the DB field will be longer than it needs to be.

[AlexHill]

I couldn't test it yesterday, but I was worried that when people run makemigrations under 1.7, migrations would see the 254-character field in migrations and the default 75 character field in the models, and want to migrate back to the shorter field.

[stephenmcd]

Right, but wouldn't they only be generating migrations for their own apps? I'm not actually sure.

Could we also possibly force the length on the email field itself somehow? That might ensure the field definition always matches the migration.

[AlexHill]

I would expect to be able to run manage.py makemigrations with no app label specified without any effects outside my project, and I think that would generate migrations in Mezzanine in this case. Good point though, we can just specify the max length in the relevant model and fix this for everyone.