Last checked and updated on 09 Jun 2026
What Is New in Django 1.1
Django 1.1 introduces a set of significant enhancements that expand the framework's capabilities for building complex applications. This release focuses on delivering long-requested features and refining existing components.
| Category | Key Changes |
|---|---|
| New Features | Class-based generic views, model validation, conditional view processing, test enhancements |
| Improvements | ORM additions (expressions, aggregates), faster CSRF protection, admin refinements |
| Backwards Incompatible Changes | CSRF exception handling, URLconf import semantics, serialization format |
How did class-based views change in Django 1.1?
Django 1.1 introduced a completely new system for class-based generic views, laying the foundation for a more object-oriented approach to view handling. This was a fundamental shift from the previous function-based generic views, offering greater flexibility through inheritance and method overriding.
In practice, this meant you could now create views by subclassing from base classes like ListView or DetailView and customize their behavior by overriding methods such as get_queryset() or get_context_data(). This pattern became central to Django's design and evolved significantly in later versions.
What model validation features were added?
Model instances gained a full validation system through the new full_clean() method. This allowed for comprehensive validation of model data beyond what the database layer could enforce.
The validation process checks fields against their defined constraints, calls each field's clean() method, and executes the model's clean() method for custom validation rules. This matters because it provides a unified way to ensure data integrity before saving to the database.
How did testing improve in this release?
Testing became more powerful with the introduction of transaction-based test cases. The TestCase class now wraps each test in a transaction that gets rolled back after test completion, ensuring test isolation.
For tests that actually require database commits, the TransactionTestCase was provided. This change made test suites significantly faster by avoiding the need to rebuild the database between each test while maintaining clean separation.
What ORM enhancements arrived with 1.1?
The ORM gained support for aggregate queries and the new F() expressions. Aggregates like Count, Sum, and Avg enabled complex data summarization directly in database queries.
F() expressions allowed referencing model field values and performing database operations directly in update queries. This eliminated the need to pull data into Python for simple arithmetic operations, reducing race conditions and improving performance.
FAQ
How do I upgrade from Django 1.0 to 1.1?
Review the backwards incompatible changes first. Pay special attention to the CSRF middleware changes, URLconf import handling, and serialization format updates. Test your application thoroughly after upgrading.
What happened to the old function-based generic views?
They were deprecated but still available in the django.views.generic.simple module. The new class-based views in django.views.generic became the recommended approach.
Does model validation replace form validation?
No, they serve different purposes. Model validation ensures database integrity, while form validation handles user input cleaning and validation. You typically use both together.
When should I use TransactionTestCase vs TestCase?
Use the faster TestCase for most tests. Only use TransactionTestCase when you need to test behavior that involves database transaction commits within your test.
Are F() expressions only for numeric fields?
No, while commonly used for arithmetic, F() expressions can reference any field type and are particularly useful for incrementing counters or comparing field values directly in the database.