Last checked and updated on April 20, 2026What Is New in Django 2.1
Django 2.1 introduces a focused set of enhancements, primarily a major new feature for model view restrictions and several quality-of-life improvements for developers.
| Category | Key Changes |
|---|---|
| New Features | Model view permission, In database lookup for fields with choices |
| Improvements | Faster model saving, QuerySet explanation in shell, dbshell management
command for Oracle |
| Backend Support | Dropped support for PostgreSQL 9.3 and Oracle 11.2 |
| Miscellaneous | New django.contrib.postgres features, HttpRequest method updates |
How does the new model view permission work?
The new model view permission (can_view) allows for read-only access to objects without
granting change or delete rights. This is a major addition for applications that need to expose data for viewing
by certain users without enabling modification. The permission is created automatically for each model and can
be handled through Django's standard permission system.
In practice, this simplifies building dashboards or reporting interfaces where users should only see data. You
can check this permission in your views using request.user.has_perm('app.view_modelname') or use it
with Django's permission mixins for class-based views.
What database lookups were added for fields with choices?
You can now use the In lookup directly on fields that have their choices defined. For
example, if a field status has choices 'draft' and 'published', you can
query with Model.objects.filter(status__in=['draft']).
This matters because it provides a cleaner, more intuitive way to filter based on the allowed choice values. Previously, this was possible but the new integration makes the intent of the query clearer and more consistent with other lookups.
What performance improvements were made for saving models?
Saving model instances with multi-table inheritance is now faster. The optimization reduces the number of
database queries needed when saving a child model instance, specifically by avoiding an unnecessary
SELECT to check if the parent already exists.
This is a welcome change for data-heavy applications using complex model inheritance. The performance gain scales with the number of saves you perform, making bulk operations noticeably more efficient.
Why were older database versions dropped?
Support for PostgreSQL 9.3 and Oracle 11.2 was removed. This decision aligns with the end-of-life cycles of those database versions, allowing the Django core team to utilize newer SQL features and reduce maintenance overhead for unsupported software.
If you're upgrading to Django 2.1, you must be running at least PostgreSQL 9.4 or Oracle 12.1. This is a standard practice in the ecosystem to keep the framework modern and secure.
FAQ
Does the new view permission work with the Django admin?
Yes, the view permission integrates
with the admin. Users with only the view permission for a model will see a read-only version of the object's
detail page in the admin interface.
I use the In lookup already. What changed?
The In lookup itself isn't new. The
change is that it's now specifically supported and documented for fields with a choices attribute,
making its usage more official and clear for that context.
How do I try the improved QuerySet explanation?
Run python manage.py shell and
then print a query with print(MyModel.objects.all().query). The output is now more readable and
easier to understand for debugging purposes.
What happened to the old django.core.urlresolvers module?
It was already deprecated in an
earlier version. Django 2.1 completes its removal. You must now import from django.urls for items
like reverse and include.
Is the dbshell improvement for Oracle a big deal?
If you use Oracle, yes. The
dbshell management command now properly works with the Oracle backend, which it didn't before. It's
a small but crucial fix for developers who work directly with the database shell.