FieldError on ManyToMany after upgrading to Django 1.3

282 views
Skip to first unread message

Philip

unread,
Sep 23, 2011, 9:40:54 AM9/23/11
to Django users
Just been updating to Django 1.3.1 and come across an odd error. I'm
getting the following error from some code which works with version
1.2.7.

FieldError: Cannot resolve keyword 'email_config_set' into field.
Choices are: id, name, site, type

The odd thing being email_config_set is a related name for a
ManyToMany field. I'm not sure why django is trying to resolve it into
a field.

To make it even more odd, this error occurs when DEBUG = TRUE and not
when DEBUG = FALSE when testing with runserver.

I've been trying to solve this for days now with much googling/pdb/
logging, but since the exception originates deep inside django I'm not
familiar enough to find what is going wrong:

Traceback (most recent call last):
File "./core/driver.py", line 268, in run
self.init_norm()
File "./driver/emailevent/background.py", line 130, in init_norm
self.load_config()
File "./driver/emailevent/background.py", line 71, in load_config
events = list(config.events.select_related())
File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/manager.py", line 168, in select_related
return self.get_query_set().select_related(*args, **kwargs)
File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/fields/related.py", line 497, in get_query_set
return
superclass.get_query_set(self).using(db)._next_is_sticky().filter(**(self.core_filters))
File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/query.py", line 550, in filter
return self._filter_or_exclude(False, *args, **kwargs)
File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/query.py", line 568, in _filter_or_exclude
clone.query.add_q(Q(*args, **kwargs))
File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1194, in add_q
can_reuse=used_aliases, force_having=force_having)
File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1069, in add_filter
negate=negate, process_extras=process_extras)
File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1260, in setup_joins
"Choices are: %s" % (name, ", ".join(names)))
FieldError: Cannot resolve keyword 'email_config_set' into field.
Choices are: id, name, site, type

Any ideas/solutions/pointers/tips would be most welcome.

Philip Mountifield

unread,
Sep 26, 2011, 4:27:05 AM9/26/11
to Django users
Has anyone else experienced this error? Any help would be appreciated.

Thanks

Philip

Russell Keith-Magee

unread,
Sep 26, 2011, 6:16:27 AM9/26/11
to django...@googlegroups.com
Hi Philip,

I can't say I've seen the error you report.

My immediate question when I see reports like this is "what else are
you doing?". Django has an extensive test suite, and things like m2m
fields are tested very heavily. Outside of Django's test suite, there
are thousands of applications out there using Django, and many of them
are using Django 1.3, and this is the first time that this particular
problem has been reported. So, you are clearly doing *something* that
is unusual (whether you know it's unusual or not).

What we need is a reproducible test case -- the smallest possible
sample of code that works under 1.2.7, but breaks under 1.3.1. That
will provide us the basis on which to debug the problem, and form the
core of a regression test to make sure the problem doesn't occur again
in the future.

Yours,
Russ Magee %-)

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

David Markey

unread,
Sep 26, 2011, 6:20:29 AM9/26/11
to django...@googlegroups.com
I had some problems with 1.3 and Postgres 8.1,

Are you using psycopg2 and pg 8.1?

Matthias Kestenholz

unread,
Sep 26, 2011, 6:27:16 AM9/26/11
to django...@googlegroups.com
Hi Philip

On Fri, Sep 23, 2011 at 3:40 PM, Philip <pmount...@formac.net> wrote:
> FieldError: Cannot resolve keyword 'email_config_set' into field.
> Choices are: id, name, site, type
>
> Any ideas/solutions/pointers/tips would be most welcome.

Yes, I've seen similar problems in two sites I'm running. I suspect it
has to do with dynamically created models and startup timing effects
in our case. I'm not sure when it started and it's really hard to test
because it only happens in production (mod_wsgi / DEBUG=False) and I
don't have a consistent view of when the problem happens yet.

What we are doing in FeinCMS against it is trying to remove the caches
on Model._meta when new models are being created; this works for us,
but isn't all that nice. I'm running the following code in production
and will be waiting a few hours / days for the problem to manifest
itself again, hoping it wont:
https://github.com/matthiask/feincms/commit/f2de708a09f8b6cf4fdbca6b3583747b6ebbc2e2


Matthias

Philip Mountifield

unread,
Sep 26, 2011, 6:30:10 AM9/26/11
to django...@googlegroups.com
I am indeed using psycopyg2 and pg8.1, which version did you move to in order to solve the problem? I have just been using 8.1 since it was the default for CentOS 5, but I also see the 8.4 is available via yum.

Philip
-- 

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmount...@formac.net
www.formac.net
www.telgas.net

Philip Mountifield

unread,
Sep 26, 2011, 6:34:32 AM9/26/11
to django...@googlegroups.com
I also have a great deal of dynamically generated models. Interestingly
in my case I find the issue when using the development server with DEBUG
= TRUE, I've not yet tried it in deployment.

I'll take a look at your github, thanks for sharing the link.

Out of interest, with respect to David's comment about postgres
versions, do you use version 8.1 or another?

Phil

Matthias Kestenholz

unread,
Sep 26, 2011, 6:36:32 AM9/26/11
to django...@googlegroups.com
On Mon, Sep 26, 2011 at 12:34 PM, Philip Mountifield
<pmount...@formac.net> wrote:
> I also have a great deal of dynamically generated models. Interestingly in
> my case I find the issue when using the development server with DEBUG =
> TRUE, I've not yet tried it in deployment.
>
> I'll take a look at your github, thanks for sharing the link.
>
> Out of interest, with respect to David's comment about postgres versions, do
> you use version 8.1 or another?
>

We don't (unfortunately, but that's a different topic) on the site in question.


Matthias

David Markey

unread,
Sep 26, 2011, 6:36:32 AM9/26/11
to django...@googlegroups.com
I actually haven't moved.. I'm still using django 1.2.x. :)

Although we plan to move to PG 9.1 and django 1.3 within the next few weeks(we are already using both in testing)

I think i read something somewhere in the django 1.3 documentation that PG 8.1 was not supported any more(could have dreamt it though).

Matthias Kestenholz

unread,
Sep 26, 2011, 6:37:15 AM9/26/11
to django...@googlegroups.com
On Mon, Sep 26, 2011 at 12:36 PM, Matthias Kestenholz <m...@spinlock.ch> wrote:
> On Mon, Sep 26, 2011 at 12:34 PM, Philip Mountifield
> <pmount...@formac.net> wrote:
>> I also have a great deal of dynamically generated models. Interestingly in
>> my case I find the issue when using the development server with DEBUG =
>> TRUE, I've not yet tried it in deployment.
>>
>> I'll take a look at your github, thanks for sharing the link.
>>
>> Out of interest, with respect to David's comment about postgres versions, do
>> you use version 8.1 or another?
>>

(Sorry for pressing send too early.)


We don't use postgresql at all (unfortunately, but that's a different

Philip Mountifield

unread,
Sep 27, 2011, 8:50:20 AM9/27/11
to django...@googlegroups.com
So I've had a further look into this.

Firstly, I updated to PG 8.4, and found the the issue is still there.
Secondly I had a look at Matthias' code on github and tries a few hacks.
I found that clearing the caches on the opposite side of the many to
many relationship solved the problem.

E.g. for "an_instance.a_many_to_many_field" I cleared the caches in
"an_instance.a_many_to_many_field.model._meta"

Now I'm going to look into the creation of the dynamic models to see
what has changed between Django 1.2 and 1.3 in how this happens and
their sequence.

Philip

Reply all
Reply to author
Forward
0 new messages