id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 27365 Fields suddenly not found. Brandon nobody "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: {{{ StartServers 2 MinSpareThreads 25 MaxSpareThreads 75 ThreadLimit 64 ThreadsPerChild 25 MaxRequestWorkers 150 MaxConnectionsPerChild 5000 }}} 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" Bug closed Database layer (models, ORM) 1.9 Normal invalid FieldDoesNotExist Unreviewed 0 0 0 0 0 0