M2M frustration

[Joris]

Dear all, please help me with this unsolved mystery.

Error: "Cannot resolve keyword u'<M2M FIELD NAME>' into field. Choices
are: <fields of the M2M model>"


1) Error in admin
In the admin it only happens when DEBUG=True. Works perfectly when
DEBUG=False.
The error occurs when opening the form view of the model that has the
M2M field.

2) In code
Here the error is also present when DEBUG=False.
The error occurs when accessing the model field, field, for example
self.my_m2m_field.all()


The error doesn't happen locally on the Django/Python debug server. On
the testing server, which is Apache2 + wsgi, it does occur. The versions
of Python (2.7) and Django (1.5.7) are the same on both computers.
The result is that a fellow developer is accusing me of being neglective
with testing the code before uploading it :-(

There have been people with similar problems, but it has never been solved:
https://groups.google.com/forum/#!topic/django-users/E4UVZHf6kP8
http://stackoverflow.com/questions/19145787/fielderror-cannot-resolve-keyword-xxxx-into-field
http://chase-seibert.github.io/blog/2010/04/30/django-manytomany-error-cannot-resolve-keyword-xxx-into-a-field.html
http://code.djangoproject.com/ticket/1796 (7 year old django bug which
is reported fixed but in fact is not)


So it seems to be a bug deep down in Django.
This makes the use of M2M fields impossible for my application, which is
quite a problem.

Instead of trying to find the bug in Django, would anyone have any clue
why it does work on the Python debug server and not on Apache2?


Thank you!
J

[Yusuf Düzgün]

http://yusufduzgun.com/blog/Django404/ i hope help you :) .

17 Mayıs 2014 Cumartesi 19:20:56 UTC+3 tarihinde Joris yazdı:

[Mark Phillips]

Jorris,

Have you tried changing the order of imports in your model? From a quick read of the references, that helped some folks.

Mark

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/53778C68.4060102%40promani.be.
For more options, visit https://groups.google.com/d/optout.

[Olga Burdonova]

unsubscibe

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f4184af8-10a5-4d84-b92f-448b830a1b8f%40googlegroups.com.

[François Schiettecatte]

Olga

This won't work, you need to send the request to:

django-users...@googlegroups.com

(see the bottom of this email for more information.

François

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAEKo5h_GNuc6OAD%3DnULOUvthpY5z5%2BBJuY80GFZ5eUZshu-83Q%40mail.gmail.com.

[Joris]

Dear Mark,

Thanks for your suggestion.

Yes, more or less, I've been playing with the order but the models are so complex with lots of overrides and many fields that it's hard to keep track. Also the Python/Django backtrace is useless here.

I just find it so curious that all of this doesn't happen on the Python debugging webserver...

Joris

op 18-05-14 21:41, Mark Phillips schreef:

To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/53778C68.4060102%40promani.be.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAEqej2Oarfwzoy7Pi%3Dk01pBD9a6TiyQnUbuSaEXSfPW8exug-Q%40mail.gmail.com.

[Russell Keith-Magee]

Hi Joris,

It's an edge case, but there are a small number of circumstances where it is possible to get different behaviour in the development server vs Apache/production. The problems usually stem from import side effects, especially those caused by circular references in imports.

The reason these bugs manifest is that the startup sequence for Django (pre 1.7) isn't strictly controlled. In development, there is a predictable startup order -- the validate management command is executed as part of starting the development server, and this validate step does a predictable import of all models modules. However, in production, validate isn't run (after all, it shouldn't be needed); so the way certain references are resolved is affected by the way that the first queries are issued. It is therefore theoretically possible to end up with subtle differences in FK and M2M resolution between development and production.

The immediate fix - put a manual call to the validate management command in your WSGI file. This will add a slight startup overhead to the first request, but will result in a predictable startup order. Graham Dumpleton explains how (and some of the why) in this blog post:

http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html

(The other solution is to simplify your module structure so that the problem circular references don't exist - but it's a lot harder to point at a simple fix. Over the years, we've spent a lot of time resolving issues with model references, and we've fixed all the problems we're aware of… but it's the nature of edge cases to be hard to track down)

The good news is that in Django 1.7 (soon to be released), this sort of bug shouldn't happen. Django 1.7 has a predictable startup order, regardless of whether you're in production or development.

I hope this helps.

Yours,

Russ Magee %-)

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/537956B2.80809%40promani.be.

[Mark Phillips]

Joris,

I had some problems moving a django from my dev server to production (apache2 and wsgi). I found a discussion about the differences between how django starts with runserver and how it starts under wsgi...I can't find the link, but try Google with wsgi and django. I did not have the same error that you are reporting, however. But the discussion was helpful.

Have you tried replicating the production server on your development server....maybe in a virtual environment? Then you could try the "remove" and test process to find where the problem is.

That is all I can think of now....good luck!

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/537956B2.80809%40promani.be.

[Mark Phillips]

What a coincidence...Russ gave you the link I was looking for!

Mark

[Joris]

Hi Russell,


Very interesting, now everything makes sense.
And thank you for the suggested solution, we tried it today and it works now, no more random import hell.
Looking forward to Django 1.7.

Best
Joris

op 19-05-14 06:00, Russell Keith-Magee schreef:

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq84_%2B76_6ba4HhXCUD2XdqS7eMynBW5iiAJyFDBK471WweQ%40mail.gmail.com.