getting objects where column is null throws exception, when you define ordering by that column

[antje.gaida@…]

i have the following class defined:

class Foo(models.Model):
    bar = models.ForeignKey(Bar, null=True, blank=True)
    name = models.CharField(max_length=100, null=True, blank=True)
    
    class Meta:
        ordering = ['bar', 'name']

now trying to get an object throws this exception, unless you don't delete 'bar' from ordering:

>>> f = Foo(name="asdf")
>>> f.save()
>>> f.id
38500L
>>> f2 = Foo.objects.get(id=38500)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/tools/python/lib/python2.5/site-packages/django/db/models/manager.py", line 93, in get
    return self.get_query_set().get(*args, **kwargs)
  File "/tools/python/lib/python2.5/site-packages/django/db/models/query.py", line 309, in get
    % self.model._meta.object_name)
DoesNotExist: Foo matching query does not exist.

is there already a bugfix? of course there is a workaround here with order_by but you can search a very long time until you find it

thank you,

antje

[James Bennett]

Questions on how to use Django effectively (e.g., in this situation) should go to the django-users mailing list, not to the bug tracker.

[Malcolm Tredinnick]

Reopening until I check what the behaviour is here. This shouldn't be happening; if it is, some database server is broken. In that case, we should work around it.

[Malcolm Tredinnick]

I tested the example provided in the description with SQLite, PostgreSQL and MySQL using both current subversion trunk and the Django 1.0.X branch. Could not repeat the problem.

If the original reporter has more details about how to recreate this issue reliably with either trunk HEAD or Django 1.0.2, please reopen with details. We would need to know at least the database being used and what the definition of Bar is. However, I cannot see from the code how this result would be possible as a rule. It's not impossible to replicate if, say, some other thread of execution deleted the object between the creation and the get() call and the database wasn't using transactions (MYSQL with MyIsam, perhaps), but that's not a bug in Django.

For now, closing as worksforme.