[patch] "Cannot resolve keyword ___ into field" error when working with ManyToMany relation

[anonymous]

Any attempt to get the related objects from a many to many relation using all() fails. For example the line

a1.primary_categories.all()

in tests/modeltests/m2m_multiple fails with the following error:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\lib\site-packages\django\db\models\query.py", line 88, in __
repr__
    return repr(self._get_data())
  File "C:\Python24\lib\site-packages\django\db\models\query.py", line 378, in _
get_data
    self._result_cache = list(self.iterator())
  File "C:\Python24\lib\site-packages\django\db\models\query.py", line 159, in i
terator
    select, sql, params = self._get_sql_clause()
  File "C:\Python24\lib\site-packages\django\db\models\query.py", line 392, in _
get_sql_clause
    tables2, joins2, where2, params2 = self._filters.get_sql(opts)
  File "C:\Python24\lib\site-packages\django\db\models\query.py", line 523, in g
et_sql
    tables2, joins2, where2, params2 = val.get_sql(opts)
  File "C:\Python24\lib\site-packages\django\db\models\query.py", line 572, in g
et_sql
    return parse_lookup(self.kwargs.items(), opts)
  File "C:\Python24\lib\site-packages\django\db\models\query.py", line 677, in p
arse_lookup
    tables2, joins2, where2, params2 = lookup_inner(path, clause, value, opts, o
pts.db_table, None)
  File "C:\Python24\lib\site-packages\django\db\models\query.py", line 780, in l
ookup_inner
    raise TypeError, "Cannot resolve keyword '%s' into field" % name
TypeError: Cannot resolve keyword 'primary_article_set' into field

[tom]

I have the same problem here with latest SVN (rev 2934). It also occures with .count()

Has anybody got a fix?

[curtis.thompson@…]

Problem transcript

[curtis.thompson@…]

Simple Model

[curtis.thompson@…]

Attached transcript and simple model showing the problem with self referential ManyToManyField

[curtis.thompson@…]

Just another note: The odd thing about this is that when you use the Admin interface, everything works just fine. Very strange.

[curtis.thompson@…]

Patch files

[curtis.thompson@…]

Ok.. Added a patch that fixes the problem for me... Not extensively tested though...

[Luke Plant]

What database are you using? The 'a1.primary_categories.all()' line works fine for me, and I added your model to the m2m_recursive tests and tried it out and it works fine. I've tried using postgres and mysql.

[curtis.thompson@…]

This happens when using sqlite3. I'll try MySQL if I get a chance.

[anonymous]

Ok. Verified that my 'models.py' attached example fails with MySQL as well (and the patch fixes the problem)

[curtis.thompson@…]

More interesting info: Django tests run fine without my patch. The m2m_recursive test fails ('idol' part) with my patch. So the patch is NOT recommended. When I add the 'Person' model to my models, run 'manage.py shell' and manually run the m2m_recursive tests, it fails. So perhaps something isn't being included/initialized properly?

[Simon Willison]

I'm seeing the same error, using mysql and a current checkout from SVN:

>>> e.tags.all()
Traceback (most recent call last):
  File "<console>", line 1, in ?
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/django/db/models/query.py", line 88, in __repr__
    return repr(self._get_data())
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/django/db/models/query.py", line 395, in _get_data
    self._result_cache = list(self.iterator())
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/django/db/models/query.py", line 162, in iterator
    select, sql, params = self._get_sql_clause()
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/django/db/models/query.py", line 409, in _get_sql_clause
    tables2, joins2, where2, params2 = self._filters.get_sql(opts)
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/django/db/models/query.py", line 540, in get_sql
    tables2, joins2, where2, params2 = val.get_sql(opts)
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/django/db/models/query.py", line 589, in get_sql
    return parse_lookup(self.kwargs.items(), opts)
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/django/db/models/query.py", line 697, in parse_lookup
    tables2, joins2, where2, params2 = lookup_inner(path, clause, value, opts, opts.db_table, None)
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/django/db/models/query.py", line 800, in lookup_inner
    raise TypeError, "Cannot resolve keyword '%s' into field" % name
TypeError: Cannot resolve keyword 'entry' into field
>>> 

[Luke Plant]

This is very strange. From what I know of that exception, is very unlikely to be DB related -- that exception occurs long before any DB calls are made. So I thought maybe it would be Python version -- but i've just tested with Python 2.3, as well as 2.4, with postgres, mysql and sqlite3, and I simply can't reproduce this. I'm guessing it's one of those subtle dict ordering things, or perhaps a mutable default argument type thing, seeing as it doesn't seem to happen with a simple run through of the tests.

I actually noticed lots of mutable default arguments in django.forms, and there are other ones around the place -- such as one in SortedDict, which could easily be relevant. We really need to go through the code and get rid of them all, but there are one or two I'm not sure about -- such as MultiValueDict.__deepcopy__().

Assuming we've followed PEP 8 (which seems to be the case pretty much everywhere), these two commandlines should find most of them:

egrep -r '=\{\}' *
egrep -r '=\[\]' *

I've no idea whether that's actually related, but it's worth sorting out anyway. I'm off to bed now and not likely to be available until Monday, so if someone else wants to do this they won't be treading on my toes :-)

[Adrian Holovaty]

(Fixed formatting in description.)