migration fails for models with order_with_respect_to during creation of fakeorm

[AmanKow]

Adding migrations to an existing app.
Added south to installed app then did a startmigration --initial.
Failure ocurred when attempting to do migrate --fake :

class FurtherInterest(Model):
    order_number = IntegerField()
    activity_topic = ForeignKey(ActivityTopic)
    question = CharField(max_length=128)

    class Meta:
        ordering = ['order_number']
        unique_together = (('order_number', 'activity_topic'),)
        order_with_respect_to ='activity_topic'
        verbose_name = 'Further Interest'

It appears to be trying to find activity_topic in the field list, although it's my understanding that fk's hang in a separate list.

$ manage.py migrate pwf --fake
While loading migration 'pwf.0001_initial':
Traceback (most recent call last):
  File "./manage.py", line 11, in <module>
    execute_manager(settings)
  File "/usr/lib/python2.5/site-packages/django/core/management/__init__.py", line 350, in execute_manager
    utility.execute()
  File "/usr/lib/python2.5/site-packages/django/core/management/__init__.py", line 295, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 192, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 219, in execute
    output = self.handle(*args, **options)
  File "/usr/lib/python2.5/site-packages/south/management/commands/migrate.py", line 67, in handle
    load_inital_data = True,
  File "/usr/lib/python2.5/site-packages/south/migration.py", line 386, in migrate_app
    tree = dependency_tree()
  File "/usr/lib/python2.5/site-packages/south/migration.py", line 103, in dependency_tree
    tree = all_migrations()
  File "/usr/lib/python2.5/site-packages/south/migration.py", line 98, in all_migrations
    for app in get_migrated_apps()
  File "/usr/lib/python2.5/site-packages/south/migration.py", line 84, in get_migration
    migclass.orm = FakeORM(migclass, get_app_name(app))
  File "/usr/lib/python2.5/site-packages/south/orm.py", line 40, in __init__
    self.models[name.lower()] = self.make_model(app_name, model_name, data)
  File "/usr/lib/python2.5/site-packages/south/orm.py", line 172, in make_model
    fields,
  File "/usr/lib/python2.5/site-packages/django/db/models/base.py", line 154, in __new__
    new_class._prepare()
  File "/usr/lib/python2.5/site-packages/django/db/models/base.py", line 174, in _prepare
    opts._prepare(cls)
  File "/usr/lib/python2.5/site-packages/django/db/models/options.py", line 105, in _prepare
    self.order_with_respect_to = self.get_field(self.order_with_respect_to)
  File "/usr/lib/python2.5/site-packages/django/db/models/options.py", line 263, in get_field
    raise FieldDoesNotExist, '%s has no field named %r' % (self.object_name, name)
django.db.models.fields.FieldDoesNotExist: furtherinterest has no field named 'activity_topic'

[AmanKow]

The issue appears to happen at the time that the stub models for referred to models are created (FurtherInterest? is indeed referenced by FurtherInterestResponse? in my models). Removing the lines for the further interest class in the Migration.models attribute removed this failure, and instead I fail when the next class with references to it and an order_with_respect_to attr in its Meta is hit.

I removed the lines defining the order_with_respect_to in the Meta entry for each of the stub models having this attribute, and the fake migration went ahead. However, I have no idea of how this will affect real migrations going forward.

Hope this additional info is of some small use.

[andrew]

Yes, thanks; I'll try and fix this when I get home in an hour or two.

[anonymous]

Just a bit of further info:

It appears that the creation of the stub classes just passes in the Meta to type when building the stub. At that time, Django creates the model, and in the case of with an order with respect to, tries to obtain the actual field and store it rather than store the name (as happens, for instance, with order_by or unique_together).

As the stubs only contain id fields, kaboom!

Perhaps, when stub is true, order_with_respect_to (or a list of Meta options that behave in a similar) should be filtered out of the Meta? Or, is the Meta truly necessary at all when creating a stub? If it isn't, not passing it in when making a stub could prevent more of these issues from arising should some other Meta setting that hasn't been tested attempts to access a model field other than id.

Thanks for your attention to this!
Wayne

[andrew]

You, good sir, are precisely correct. Fixed in [166].

Please report bugs in this much detail in future, it's immensely useful!