I am building an application using django, and using django-south for the database schema migrations. I'm using django-mptt to build a comment system, and I installed 0.5-pre (the current git master branch).
The version I'm using has a django-field called TreeForeignKey
, but I'm trying to test whether or not 0.5 has a bug that exists in 0.4, so I removed my version of django-mptt and installed the current release from the cheeseshop. I modified my code to use ForeignKey
rather than TreeForeignKey
.
When it comes time to do migrations, it obviously breaks with this message:
ValueError: Cannot import the required field 'mptt.fields.TreeForeignKey'
All my migration files reference mptt.fields.TreeForeignKey
, which doesn't exist in django-mptt 0.4.
My Comment
model in django-mptt 0.5:
from mptt.models import MPTTModel
from mptt.fields import TreeForeignKey
class Comment(MPTTModel):
# ...
parent = TreeForeignKey('self', related_name='children', blank=True, null=True)
The same model after I downgrade to django-mptt 0.4
import django.db.models
from mptt.models import MPTTModel
class Comment(MPTTModel):
# ... cruft
# TreeForeignKey does not exist in mptt 0.5!
parent = models.ForeignKey('self', related_name='children', blank=True, null=True)
There are two rather hacky approaches I came up with to fix this and allow the migration to work:
TreeForeignKey
class to my django-mptt install.mptt.fields.TreeForeignKey
.I took the first approach and it worked, but I feel it's kind of a hack (but not as much as the second option).
Is there a non-hacky way to do what I did with downgrading dependencies that resulted in some fields changing in my models?
This really has nothing to do with South. the fields
module of django-mptt didn't exist before 0.5.pre. So when you downgraded to 0.4, you're now rightly getting an ImportError.
I can't tell you what the proper import to use is because I'm not running 0.4 and for some crazy reason the developers did not maintain the 0.4 docs. However, your second approach seems most appropriate. There shouldn't be any reason you need to actually use TreeForeignKey in migration. It's simply a wrapper around a standard ForeignKey.