Missing migration for Revision.project null=True

[squiddy]

I was going to work on #35, but when I wanted to create a new migration, south found another change:

$ python manage.py schemamigration codespeed --auto
 ? The field 'Revision.project' does not have a default specified, yet is NOT NULL.
 ? Since you are making this field nullable, you MUST specify a default
 ? value to use for existing rows. Would you like to:
 ?  1. Quit now, and add a default to the field in models.py
 ?  2. Specify a one-off value to use for existing columns now
 ?  3. Disable the backwards migration by raising an exception.

In 6cefd8e null=True was added to the definition of Revision.project, but apparently no migration was added.

If I'm not mistaken, each revision has a link to a project (a revision belongs to a branch, and that branch belongs to a project). Why can project be left out on a revision then?

[tobami]

It is for historical reasons. Migrating from Revision->Project to Revision->Branch->Project was a bit messy (there are several scripts to migrate an old DB). In order for the migration to work, revision.project was left there.

I also do not like that python manage.py syncdb doesn't leave you with a new, clean DB. You need an extra step.

It would be a task for the next release (1.0.0?) to remove this migration artefact.

[squiddy]

I also do not like that python manage.py syncdb doesn't leave you with a new, clean DB. You need an extra step.

Agreed. It probably is helpful to users migrating projects across releases, but is has its downsides (spending hours trying to migrate complex schema changes - what some lines of SQL can achieve).

But the issue is still there. I had to add a migration in two branches now to keep the commits separated. Should we include the migration that is missing (to have a clean base) or remove Revision.project right away? In my opinion, one of these should be done, if you plan to keep using south.

[tobami]

IMO removing Revision.project would be a cleaner solution looking forward

[squiddy]

Alright, I'll send a pull request then.

[tobami]

@squiddy do you intend to send a pull request for this yet?

[squiddy]

Yes, I'll send one today. Better late than never.

[tobami]

Great, thanks

[squiddy]

Hm, I underestimated the work involved. I doubt I'll have time for this.

First thing I noticed is that there seems to be a migration conflict. Two migrations occupy the same timeslot, 0011. Apparantly the conflict was not resolved, therefore south does not detect the 'commit_browsing_url' migration here and wants to create a new one. I don't know if recreating it as 0012 and deleting the old is enough.

Removing Revision.project breaks a lot of API tests. I had a quick look at the code, but it would take some time to understand it. Maybe a8 can help here?

[tobami]

Migrations are clean now