Validation of erroneous data model breaks with AttributeError instead of a useful message (like it used to)

[raik.gruenberg@…]

I've updated the data model of my django project and run manage.py sql <app_name> to check the changes.
I obviously made an error but rather than reporting it, the current svn revision of django breaks with the following traceback:

brickitserver|~/py/djbrickit> python manage.py sql repository
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 180, in execute_manager
    utility.execute(argv)
  File "/usr/lib/python2.5/site-packages/django/core/management/__init__.py", line 124, in execute
    command.execute(*args[1:], **options.__dict__)
  File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 33, in execute
    self.validate()
  File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 60, in validate
    num_errors = get_validation_errors(s, app)
  File "/usr/lib/python2.5/site-packages/django/core/management/validation.py", line 72, in get_validation_errors
    rel_opts = f.rel.to._meta
AttributeError: 'str' object has no attribute '_meta'

By contrast, svn revision 5000 gives this nice informative error message for the same command:

brickitserver|~/py/brickit/djbrickit> python manage.py sql repository
Error: One or more models did not validate:
djbrickit.repository: name 'BRICK_Format_CHOICES' is not defined

The offending part of my model looks like this:

class Biobrick:
   BRICK_FORMAT_CHOICES = ( ('classic', 'classic biobrick format'),... )
   ...
   brick_format = models.CharField( 'format of Biobrick', maxlength=30,
                                   choices=BRICK_Format_CHOICES,
                                   default='classic' )
   ...

[raik.gruenberg@…]

data model with errors

[raik.gruenberg@…]

Update: There seem to be more actual errors in my data model. I am attaching the whole file in case anyone wants to reproduce the bug. That also means that revision 5000 is not necessarily better than 6031 but may only validate things in a different order.

[raik.gruenberg@…]

Final update: The actual error in my model was the following:

    #: obligate
    brick_type = models.ForeignKey( 'type of Biobrick',
                                    verbose_name='biobrick type',
                                    related_name='child_biobricks')

So I defined a ForeignKey without giving the correct Model class to refer to. The same can happen easily by simple spelling mistakes. Some more informative error message would be nice.
THX
Raik

[Adam Vollrath]

I've also encountered this bug. I believe this is the problem in my model:

class Artwork(models.Model):
    tags = models.ManyToManyField('ZTag', blank=True, null=True)

class Tag(models.Model):
    name = models.SlugField(primary_key=True)

Notice that 'ZTag' in Artwork.tags should be 'Tag'. Changing that fixed the error. This happened when I was refactoring my model and missed one string literal, so I imagine it could happen to others.
So it looks like it affects ManyToManyField as well.
I'm going to look into core.management.validation and see if I can fix it.

[Adam Vollrath]

I now think this bug is a duplicate of #3323 or maybe even #1662
foo.rel.to is called many times in db.models.options