Opened 10 years ago

Closed 10 years ago

#2287 closed defect (invalid)

db search lookup api can't work

Reported by: wlt008@… Owned by: Adrian Holovaty
Component: Database layer (models, ORM) Version: master
Severity: normal Keywords: db search
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


it works on previous version of django, but can't work with svn version. an exception throwed if use that:

UnboundLocalError at /main/tag/chinese/json_page/
local variable 'new_opts' referenced before assignment
Request Method: GET
Request URL:
Exception Type: UnboundLocalError
Exception Value: local variable 'new_opts' referenced before assignment
Exception Location: /usr/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/db/models/ in lookup_inner, line 855

Change History (8)

comment:1 Changed 10 years ago by Malcolm Tredinnick

Can you please post an example of the models that you are using and the type of lookup statement you are trying to execute. Bascially, an example that causes the error every time would be nice. There are too many paths to line 855 in to be able to work out what is really going wrong here from the information you have given so far.

comment:2 Changed 10 years ago by kilian.cavalotti@…

I have the same kind of errors, with the following (simplified) models:

class Subnet(models.Model):
    name = models.CharField(maxlength = 255, unique = True)

class IP(models.Model):
    ip  = models.IPAddressField(unique = True)
    net = models.ForeignKey(Subnet)

The following commands produce an error:

>>> i = IP.objects.get(id = 1)
>>> i.ip
<Subnet: foo>
>>> # Directly accessing related object properties works
>>> # But filtering seems to be broken
>>> IP.objects.filter(ip__net__name__exact = 'foo')
Traceback (most recent call last):
  File "<console>", line 1, in ?
  File "/home/kilian/django/django/db/models/", line 97, in __repr__
    return repr(self._get_data())
  File "/home/kilian/django/django/db/models/", line 430, in _get_data
    self._result_cache = list(self.iterator())
  File "/home/kilian/django/django/db/models/", line 171, in iterator
    select, sql, params = self._get_sql_clause()
  File "/home/kilian/django/django/db/models/", line 444, in _get_sql_clause
    tables2, joins2, where2, params2 = self._filters.get_sql(opts)
  File "/home/kilian/django/django/db/models/", line 575, in get_sql
    tables2, joins2, where2, params2 = val.get_sql(opts)
  File "/home/kilian/django/django/db/models/", line 624, in get_sql
    return parse_lookup(self.kwargs.items(), opts)
  File "/home/kilian/django/django/db/models/", line 735, in parse_lookup
    tables2, joins2, where2, params2 = lookup_inner(path, clause, value, opts, opts.db_table, None)
  File "/home/kilian/django/django/db/models/", line 866, in lookup_inner
    joins[backend.quote_name(new_table)] = (
UnboundLocalError: local variable 'new_opts' referenced before assignment

It appears that accessing related object through

comment:3 Changed 10 years ago by kilian.cavalotti@…

(damn, been cut in the middle of my sentence.)
... filtering interface does not work anymore.

comment:4 Changed 10 years ago by kilian <kilian.cavalotti@…>

According to my basic understanding, the problem seems to occur at [source:django/trunk/django/db/models/]

        # Does the name belong to a one-to-one, many-to-one, or regular field?
        field = find_field(name, current_opts.fields, False)
        if field:
            if field.rel: # One-to-One/Many-to-one field
                new_table = current_table + LOOKUP_SEPARATOR + name
                new_opts =
                new_column =
                join_column = field.column

            raise FieldFound

field is found, but field.rel returns 'None'.

comment:5 Changed 10 years ago by anonymous

This example of something that doesn't work looks more like a case of bad syntax. You should be querying IP.objects.filter(net__name__exact = 'foo') (rather than ip__net__...). If you filter that way, it does work as expected.

So we still need an example of something that actually fails and uses valid syntax (although this case does point out that the error message might be fixable, although it may be fiddly, since we can potentially be very deeply nested at that point).

comment:6 Changed 10 years ago by kilian <kilian.cavalotti@…>

Indeed, my bad, sorry.
So, worksforme.

comment:7 Changed 10 years ago by anonymous

#2348 at least describes a way to trigger this error, even if only due to bugs outside of Django. Lacking further information here, we can probably close this at the same time as that one.

comment:8 Changed 10 years ago by Simon G. <dev@…>

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.
Back to Top