Opened 18 years ago
Closed 9 years ago
#4065 closed New feature (fixed)
Ability to disable admin pagination
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | contrib.admin | Version: | dev |
Severity: | Normal | Keywords: | nfa-changelist |
Cc: | pythonmailing@…, boxm@…, mmitar@…, cmawebsite@…, Dale Hui | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Today I needed to disable pagination for Django admin - and ran into trouble, since there is no explicit option to disable it. There is list_per_page
but this only controls how many objects are displayed. Its not possible to set it to None
because that throws an exception and setting it to 0
creates a ZeroDivisionException
which is also not what I wanted. Finally, I set it to sys.maxint
, which sure will be enough.
My idea would be to rename this setting (maybe only in newforms-admin not to break backward compatibility) and make None
or False
the setting for "disable pagination". Of course, this can also be implemented without breakting backwards compatibility, but list_per_page = None
sounds odd.
Change History (22)
comment:1 by , 18 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:2 by , 18 years ago
comment:3 by , 17 years ago
Owner: | changed from | to
---|
neforms-admin should make this easier; assigning to xian just in case he comes up with some template magic for it.
comment:4 by , 17 years ago
Triage Stage: | Design decision needed → Someday/Maybe |
---|
comment:5 by , 17 years ago
Keywords: | nfa-changelist added |
---|
comment:7 by , 14 years ago
Owner: | changed from | to
---|
I'm working on a patch for this, basically, the same thing done in r14828, allow custom Paginators, but for the Admin app.
(Possibly there could be a "NullPaginator" class that always put everything on Page 1.)
follow-up: 9 comment:8 by , 14 years ago
Isn't this issue fixed?
See http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.paginator
comment:9 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Replying to kmike:
Isn't this issue fixed?
See http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.paginator
One could argue, that Django should also provide the "NullPaginator" class, but you're right that the main issue here is fixed in Django 1.3
comment:10 by , 14 years ago
Resolution: | fixed |
---|---|
Severity: | → Normal |
Status: | closed → reopened |
Type: | → New feature |
It is still not trivial to turn off pagination. This makes ModelAdmin impossible to use on many large tables where select count(*) takes a long time (i.e. 1M+ records on InnoDB tables).
Ideally, there would be a NullPaginator available. A nice to have would be to have an option for a 'next and previous only' paginator that doesn't give page counts or estimates of the total number of records, just next and previous page links.
comment:11 by , 14 years ago
Cc: | added |
---|---|
Easy pickings: | unset |
I've been looking at this today and there's quite a few places where the assumption that the paginator is dealing with a countable set is made. Making it work where you don't want to/can't count the number of items in the set means changing:
- the {% search %} admin tag
- the {% pagination %} admin tag
- the ChangeList class (in changelist_view method)
- the paginator to one that doesn't implement count, num_pages and page_range properties
1 & 2 can be fixed by overriding the change_list.html template to use alternative template tags (e.g. {% infinite_pagination %}). 3 requires deriving from ModelAdmin and cut'n'pasting the entire method. 4 is available here: http://code.google.com/p/django-pagination/source/browse/trunk/pagination/paginator.py
However this is really ugly and a lot of work for someone.
I think ideally the template tags and ChangeList class should be updated to not assume the ability to access the count, num_pages and page_range properties - ie have an "UncountedPaginator". Possibly this would be a base class of Paginator so you'd have NullPaginator (displays everything) -> UncountedPaginator -> Paginator.
comment:12 by , 14 years ago
I strongly agree with boxm on this one. Counting the number of records is often most onerous for the very sets that need to be paginated. The UncountedPaginator is a great solution.
comment:13 by , 14 years ago
Patch that implements above idea on #8408 - this should enable a NullPaginator to work with admin
comment:14 by , 13 years ago
Cc: | added |
---|---|
UI/UX: | unset |
comment:15 by , 12 years ago
Triage Stage: | Someday/Maybe → Accepted |
---|
comment:16 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
comment:17 by , 12 years ago
Owner: | changed from | to
---|
Please don't assigned tickets to people without their consent. I'm not going to work on this.
comment:18 by , 10 years ago
Cc: | added |
---|
I believe this issue is fixed in 1.8 by the show_full_result_count
option (ticket #8408 mentioned above).
Can everything else be handled by setting list_per_page
to a very large number?
comment:19 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:20 by , 9 years ago
Cc: | added |
---|---|
Resolution: | fixed |
Status: | closed → new |
show_full_result_count
does not fix the issue as paginator.count
is still called:
https://github.com/django/django/blob/1.8.3/django/contrib/admin/views/main.py#L177
comment:21 by , 9 years ago
It does fix the issue, since paginator.count
return total number of objects - https://github.com/django/django/blob/1.8.3/django/core/paginator.py#L66
Thus, I believe the ticket could be closed.
comment:22 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I created a thread on this in the django-developers Google Group, to find a reasonable solution.