Security News
Research
Data Theft Repackaged: A Case Study in Malicious Wrapper Packages on npm
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
django-admin-cursor-paginator
Advanced tools
Drop-in replacement for django admin default pagination that works fast with huge tables.
Drop-in replacement for django admin default pagination that works fast with huge tables.
str()
and then be used in queryset.filter()
NOTE
If ordering field is not unique then pagination can mess a bit in edge cases. But for the most often case with datetime fields with milliseconds likecreated_at
it won't be a problem. It can be solved in future by adding support for multiple ordering fields.
All you need is to install it via pip
like that:
pip install django-admin-cursor-paginator
...and extend INSTALLED_APPS
(it is needed only for templates):
INSTALLED_APPS = [
'django.contrib.admin',
# ...
'admin_cursor_paginator',
# ...
]
NOTE
This app overrides{% block pagination %}
in defaultchange_list.html
to insert custom pagination template tag, so if you use patchedchange_list.html
too, don't forget to copy pagination block or (seems better) to inherit this app tpl like{% extends 'admin_cursor_paginator/change_list.html' %}
.Also, there's a known issue with grapelli that is fixed the same way.
So this app will certainly help you if you're using admin to see some (usually) last inserted entries and may be also want to search for particular objects.
But anyways it's just a regular django admin page.
from admin_cursor_paginator import CursorPaginatorAdmin
class YourModelAdmin(CursorPaginatorAdmin):
cursor_ordering_field = '-created_at' # default is '-pk'
class AnotherModelAdmin(CursorPaginatorAdmin):
cursor_ordering_field = 'parent__sort' # joins are supported as well
Default django admin list view makes several queries to show data.
The first one is something like select count(*) from app_model
to calculate pages range
and select * from app_model limit 10 offset 1000
to fetch current page data.
Both of them start to produce performance problems as your table grows.
For example, with >1M entries in postgresql table count(*)
took a few seconds (in our case) because of seq scan.
Limit+offset also performs badly on far pages.
The solution is to use cursor pagination instead of default one (you can find many standalone packages for it).
It doesn't need count(*)
query at all and performs fast by using filter instead of limit+offset.
Some useful links:
In testproject
folder you can (surprisingly) find test project that uses this app
for one model so that you can see live example and check how it works if you want.
All you need is to install requirements from requirements.txt
in some env,
run ./manage.py runserver
, login as admin:admin to django admin and open Product
list.
Project includes sqlite3 file with some test data and preinstalled debug_toolbar
to observe db queries.
You can play with ordering field or data amount or may be test it in your target db.
Example of how pagination will look like:
FAQs
Drop-in replacement for django admin default pagination that works fast with huge tables.
We found that django-admin-cursor-paginator demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.