{{{
def my_fbv(request):
return HttpResponse('yay')
# urls.py
urlpatterns = [
url('whatever', my_fbv, name='my_fbv'),
]
}}}
It is possible to do the following:
{{{
from django.core.urlresolvers import resolve
from pickle import dumps, loads
loads(dumps(resolve('whatever')))
}}}
and end up with a working `ResolverMatch`
However, given a Class Based View (mapped to a urlconf via
`MyView.as_view()`), or something like contrib.admin, you get something
like the following:
{{{
dumps(resolve('/admin/myapp/'))
[...]
# for the admin ...
PicklingError: Can't pickle <function app_index at 0x109f05de8>: it's not
found as django.contrib.admin.sites.app_index
# for a CBV:
PicklingError: Can't pickle <function Homepage at 0x109f16b90>: it's not
the same object as myapp.views.Homepage
}}}
Both of which are raised by pickle's `save_global(self, obj, name, pack)`
which recognises that it's a module+name combo (thus should be in scope)
but isn't the same object in identity (`if x is not y`)
Ordinarily, this is not a problem, but `resolver_match` is set onto a
`request`, and I'm using the `django.test.client.Client` with
multiprocessing, which requires the ability to pickle data to send back
and forth, and evidently somewhere within the `TemplateResponse`s I'm
dealing with, the request is being serialised (if I had to guess --
probably in the context) and is '''sometimes''' failing (depending on the
type of view mounted)
Ideally, every `ResolverMatch` should be serialisable, or none should be,
instead of the current situation where the project's urlconf may denote
success or failure.
--
Ticket URL: <https://code.djangoproject.com/ticket/23895>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_docs: => 0
* needs_tests: => 0
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/23895#comment:1>
Comment (by tomchristie):
Haven't had a chance to confirm this much but appears that on 1.8-alpha
this is consistently an issue, making responses non-cachable with
CacheMiddleware. Alternative take would be for HttpResponse to take a more
structured approach to caching - rather than simply dumping all attributes
to pickle, just store the basics that allow a fresh HttpResponse with
correct content, status code and headers to be reconstructed. (Eg. we
shouldn't expect ResolverMatch instances to be picklable, but we *should*
be constraining what we pickle for responses)
--
Ticket URL: <https://code.djangoproject.com/ticket/23895#comment:2>
* owner: nobody => zatro
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/23895#comment:3>
* has_patch: 0 => 1
* version: 1.7 => 4.0
Comment:
I've done a fix for this but it might not be the ideal solution. Thoughts?
If it's okay, please let me know anything the PR is missing.
[https://github.com/django/django/pull/14664 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/23895#comment:4>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/23895#comment:5>
* needs_better_patch: 1 => 0
Comment:
I've now made the changes discussed and squashed the commits.
--
Ticket URL: <https://code.djangoproject.com/ticket/23895#comment:6>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/23895#comment:7>
* needs_better_patch: 1 => 0
Comment:
Changes from latest review have now been made.
--
Ticket URL: <https://code.djangoproject.com/ticket/23895#comment:8>
Comment (by zatro):
Made a new ticket #32969 for improving pickling of `HTTPResponse`s.
--
Ticket URL: <https://code.djangoproject.com/ticket/23895#comment:9>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/23895#comment:10>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"4c6a6d5ac7aa348d5b4b9a4d6bb7cc18af49f72a" 4c6a6d5a]:
{{{
#!CommitTicketReference repository=""
revision="4c6a6d5ac7aa348d5b4b9a4d6bb7cc18af49f72a"
Fixed #23895 -- Prevented pickling of ResolverMatch.
Pickling a ResolverMatch did not work correctly in many cases,
especially with CBVs and URLResolvers in the list of tried URL paths.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23895#comment:11>