[Django] #16970: ListView docs need to be more explicit in regards to model managers
Django
-------------------------------+--------------------
Reporter: pydanny | Owner: nobody
Type: Uncategorized | Status: new
Component: Documentation | Version: 1.3
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
Say I have a ListView that calls on a Thing model. Thing model has it's
own Model Manager that adds query method called 'some_things'. In theory I
code it thus:
{{{#!python
url(regex=r'^$',
view=ListView.as_view(
queryset=Thing.objects.some_things(),
template_name='things/some_things.html'),
name='some_things',
),
}}}
However, (MultipleObjectMixin.get_queryset)
https://code.djangoproject.com/browser/django/trunk/django/views/generic/list.py
shows that if a model is not defined in the ListView arguments, that the
default manager '''all''' method is called. Which means if you want to get
the behavior you want you need to do:
{{{#!python
url(regex=r'^$',
view=ListView.as_view(
model=Job,
queryset=Thing.objects.some_things(),
template_name='things/some_things.html'),
name='some_things',
),
}}}
See how I added an explicit model call?
Figuring this out meant rooting through Django source code. What I propose
is documenting this behavior in the pages on Class Based Views. I would do
it myself but it is unclear where I should put said documentation (topic
or not?).
--
Ticket URL: <https://code.djangoproject.com/ticket/16970>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------+--------------------------------------
Type: Uncategorized | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by pydanny):
* needs_better_patch: => 0
* needs_docs: => 0
* component: Documentation => Generic views
* needs_tests: => 0
Comment:
In retrospect, this is not a documentation issue but a real bug. If a
queryset is specified, why is it being overridden? So I call bug.
--
Ticket URL: <https://code.djangoproject.com/ticket/16970#comment:1>
Django
-------------------------------+--------------------------------------
Reporter: pydanny | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Changes (by pydanny):
* type: Uncategorized => Bug
--
Ticket URL: <https://code.djangoproject.com/ticket/16970#comment:2>
Django
-------------------------------+--------------------------------------
Reporter: pydanny | Owner: nobody
Component: Generic views | Version: 1.3
Severity: Normal | Resolution:
Comment (by pydanny):
I'll be documenting this with a real sample of the bug in the next 24
hours. Just need to scrape the client specific parts from the code and
paste it in.
--
Ticket URL: <https://code.djangoproject.com/ticket/16970#comment:3>
Django
-------------------------------+--------------------------------------
Reporter: pydanny | Owner: nobody
Component: Generic views | Version: 1.3
Severity: Normal | Resolution:
Comment (by ptone):
I'm assuming Job==Thing in your description.
One thing is that your queryset will be evaluated at URL import time - and
that is probably not what you wanted.
Since you want to define a custom queryset for each time the view is
visited, what you probably want is:
{{{
url(regex=r'^$',
view=ListView.as_view(
get_queryset=Thing.objects.some_things,
template_name='things/some_things.html'),
name='some_things',
),
}}}
which will result in your custom manager being called each time the view
goes to get a list of objects (see the note in the docs "Thread safety
with view arguments" in https://docs.djangoproject.com/en/1.3//ref/class-
based-views/#django.views.generic.base.View)
Furthermore, the queryset attr is only replace with a call to the default
manager if queryset is None, so I'm not sure how you would be seeing the
default manager being called in your example, even if you also set the
model
--
Ticket URL: <https://code.djangoproject.com/ticket/16970#comment:4>
Django
-------------------------------+--------------------------------------
Type: Uncategorized | Status: new
Component: Documentation | Version: 1.3
Keywords: | Triage Stage: Unreviewed
Changes (by pydanny):
* component: Generic views => Documentation
* type: Bug => Uncategorized
Comment:
I think it's pretty clear from @ptone's comment that this is not a bug
then, it's a documentation issue. Changing the ticket type accordingly.
--
Ticket URL: <https://code.djangoproject.com/ticket/16970#comment:5>
Django
-------------------------------+------------------------------------
Type: Uncategorized | Status: new
Component: Documentation | Version: 1.3
Keywords: | Triage Stage: Accepted
Changes (by ptone):
* stage: Unreviewed => Accepted
Comment:
hoping to address this in #16807
--
Ticket URL: <https://code.djangoproject.com/ticket/16970#comment:6>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: Documentation | Version: 1.3
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by iambibhas):
* cc: me@… (added)
Comment:
#16807 was fixed long time back. Is this ticket still relevant?
--
Ticket URL: <https://code.djangoproject.com/ticket/16970#comment:8>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: Documentation | Version: 1.3
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
I don't think that ticket ended up adding any clarification regarding the
issues presented here.
--
Ticket URL: <https://code.djangoproject.com/ticket/16970#comment:9>
Django
-------------------------------+------------------------------------
Type: New feature | Status: closed
Component: Documentation | Version: 1.3
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by bmispelon):
* status: new => closed
* resolution: => fixed
Comment:
I believe this issue has been fixed. I tried the following:
{{{#!python
# models.py
from django.db import models
class CustomManager(models.Manager):
def some_things(self):
return self.all()[:3]
class Thing(models.Model):
objects = CustomManager()
# urls.py
from django.conf.urls import url
from django.views.generic import ListView
from .models import Thing
urlpatterns = [
url(
regex=r'^$',
view=ListView.as_view(
queryset=Thing.objects.some_things(),
template_name='things/some_things.html',
),
name='some_things',
),
]
# tests.py
from django.test import TestCase, override_settings
from .models import Thing
@override_settings(ROOT_URLCONF='things.urls')
class ListViewTests(TestCase):
@classmethod
def setUpTestData(cls):
for _ in range(5):
Thing.objects.create()
def test_items(self):
res = self.client.get('/')
self.assertEqual(res.status_code, 200)
self.assertTemplateUsed(res, 'things/some_things.html')
self.assertEqual(len(res.context['object_list']), 3)
}}}
As noted in comment 4, there could be an issue that declaring the
`queryset` at the module-level could make the object reused between
successive calls to the view, but as noted in the documentation [1], the
default implementation of `get_queryset` prevents that by systematically
cloning the queryset object.
I'm therefore closing this.
[1] https://docs.djangoproject.com/en/1.9/ref/class-based-views/mixins-
multiple-object/#django.views.generic.list.MultipleObjectMixin.queryset
--
Ticket URL: <https://code.djangoproject.com/ticket/16970#comment:10>