#27365: Fields suddenly not found.
----------------------------------+-------------------------------
Reporter: brandon+django@… | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.9
Severity: Normal | Keywords: FieldDoesNotExist
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+-------------------------------
Hello,
We just moved from Django 1.7.10 to 1.9.9. After the move a new error
began occurring. The exception is:
{{{ FieldDoesNotExist: No related field named '...' }}}
We see the exception when accessing the reverse OneToOne of a non-abstract
models.Model subclass that has been subclassed.
{{{
class Case(models.Model):
...lots of fields...
class SubclassCase(Case):
...lots more fields...
SubclassCase.objects.get(id=12345)
}}}
generates traceback
{{{
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-
packages/django/core/handlers/base.py", line 149, in get_response
response = self.process_exception_by_middleware(e, request)
File "/usr/local/lib/python2.7/dist-
packages/django/core/handlers/base.py", line 147, in get_response
response = wrapped_callback(request, *callback_args,
**callback_kwargs)
File "/usr/local/lib/python2.7/dist-
packages/django/contrib/auth/decorators.py", line 23, in _wrapped_view
return view_func(request, *args, **kwargs)
File "/var/www/vhosts/prod/lib/workpath/workflow/views.py", line 1730,
in view_case
additional_view = case_module.view(case)
File
"/var/www/vhosts/prod/lib/workpath/workflow/cases/subclasscase/views.py",
line 286, in view
case = SubclassCase.objects.get(id=case.id)
File "/usr/local/lib/python2.7/dist-
packages/django/db/models/manager.py", line 122, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
line 378, in get
clone = self.filter(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
line 790, in filter
return self._filter_or_exclude(False, *args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
line 808, in _filter_or_exclude
clone.query.add_q(Q(*args, **kwargs))
File "/usr/local/lib/python2.7/dist-
packages/django/db/models/sql/query.py", line 1243, in add_q
clause, _ = self._add_q(q_object, self.used_aliases)
File "/usr/local/lib/python2.7/dist-
packages/django/db/models/sql/query.py", line 1269, in _add_q
allow_joins=allow_joins, split_subq=split_subq,
File "/usr/local/lib/python2.7/dist-
packages/django/db/models/sql/query.py", line 1149, in build_filter
lookups, parts, reffed_expression = self.solve_lookup_type(arg)
File "/usr/local/lib/python2.7/dist-
packages/django/db/models/sql/query.py", line 1035, in solve_lookup_type
_, field, _, lookup_parts = self.names_to_path(lookup_splitted,
self.get_meta())
File "/usr/local/lib/python2.7/dist-
packages/django/db/models/sql/query.py", line 1345, in names_to_path
targets = (final_field.remote_field.get_related_field(),)
File "/usr/local/lib/python2.7/dist-
packages/django/db/models/fields/reverse_related.py", line 244, in
get_related_field
self.field_name)
FieldDoesNotExist: No related field named 'subclasscase'
}}}
Whenever the exception occurs, it is exactly this exception every time
once {{{_filter_or_exclude}}} is reached. We've seen it in the context of
function based views, class based views, the views of our tastypie backed
API (XML and JSON) and from view functions that support light-weight JSON
functions.
We see it across multiple disconnected deployments with completely
separate machines, datastores, databases, etc.
We do not see it all the time.
We do not see it when running under the development server.
An apache restart fixes it... for a little while.
We are using mpm_event with WSGI.
Our mpm_event configuration looks like this:
{{{
<IfModule mpm_event_module>
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 5000
</IfModule>
}}}
Our WSGI ({{{libapache2-mod-wsgi 3.4-4ubuntu2.1.14.04.2}}}) configuration
looks like this:
{{{
WSGIDaemonProcess prod processes=2 python-path=/usr/local/lib/python2.7
/dist-packages:/var/www/vhosts/prod/lib
}}}
Based on our experience that an apache restart fixed it we changed our
WSGI configuration to this:
{{{
WSGIDaemonProcess prod processes=10 threads=1 maximum-requests=50 python-
path=/usr/local/lib/python2.7/dist-packages:/var/www/vhosts/prod/lib
}}}
This causes the apache children to cycle quickly and the error goes away
but as you can imagine this slows down the site considerably.
The error occurs much more frequently with 1.8.15 than with 1.9.9 - but
again it *never* occurred in 1.7.10. Based on this, and looking at {{{git
diff 1.7.10...1.9.9 -- django/db/models/options.py}}}; I believe it is
somehow related to the _meta API change and the introduction of
_get_fields_cache in the Options class.
However, I am very unfamiliar with core django code... so that could be
completely wrong.
The real difficulty here is that it seems to be time or number-of-requests
based. A apache child, immediately after a restart, hums along nicely. But
it *seems* that if any particular code path that needs to do that kind of
"reverse OneToOne" lookup is crossed too many times the error, that exact
exception, occurs. Once it has occurred for a child, that child is done.
If you access the site and get that child looking for that object, the
exception occurs. But if you get another apache child or are looking for
another object, the error has a good chance of not occurring. Again, if
that child cycles out or if Apache is restarted (not reloaded) the error
vanishes completely... for a little while, seemingly dependent on site
traffic.
I'll be glad to supply any debug information I can. As pervasive as this
error was in production, I have been unable to reproduce the problem in a
development environment. As soon as I have, I'll update the ticket with
whatever information I've found.
Any insight anyone could provide in debugging this problem would be much
appreciated. I would not hesitate to submit a patch if I had one.
Thanks,
--Brandon
--
Ticket URL: <https://code.djangoproject.com/ticket/27365>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/073.51ce40cb6a8c64c462943f7ea86346f3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
