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:
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 %-)
On Mon, May 19, 2014 at 2:56 AM, Joris <jmailli...@promani.be
<mailto:jmailli...@promani.be>> wrote:
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:
Jorris,
Have you tried changing the order of imports in your model? From
a quick read of the references, that helped some folks.
Mark
On May 17, 2014 9:24 AM, "Joris" <jmailli...@promani.be
<mailto:jmailli...@promani.be>> wrote:
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
<https://groups.google.com/forum/#%21topic/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
--
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+unsubscr...@googlegroups.com
<mailto:django-users%2bunsubscr...@googlegroups.com>.
To post to this group, send email to
django-users@googlegroups.com
<mailto:django-users@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+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to
django-users@googlegroups.com <mailto:django-users@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
<https://groups.google.com/d/msgid/django-users/CAEqej2Oarfwzoy7Pi%3Dk01pBD9a6TiyQnUbuSaEXSfPW8exug-Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.
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+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@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/537956B2.80809%40promani.be
<https://groups.google.com/d/msgid/django-users/537956B2.80809%40promani.be?utm_medium=email&utm_source=footer>.
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+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@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/CAJxq84_%2B76_6ba4HhXCUD2XdqS7eMynBW5iiAJyFDBK471WweQ%40mail.gmail.com
<https://groups.google.com/d/msgid/django-users/CAJxq84_%2B76_6ba4HhXCUD2XdqS7eMynBW5iiAJyFDBK471WweQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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/537B9399.7050007%40promani.be.
For more options, visit https://groups.google.com/d/optout.
