Django 1.7 has been released with a new built-in database migration system and an extensible system check framework that can assist developers in detecting and diagnosing errors.
Prior to release of 1.7, Django applications were tied to the existence of a models file. But with the latest release of version 1.7, developers will be able to specify both configuration data and code to be executed as Django starts up.
Django 1.7 also brings in improvements to the model Field API, custom manager and QuerySet classes. With the help of schema migrations support, you will be able to update, change and delete models by creating migration files that represent the model changes and which can be run on any development, staging or production database.
Some of the important features related to migrations are as follows
- syncdb has been deprecated and replaced by migrate.
- New makemigrations commands such as pre_migrate and post_migrate to autodetect changes to your models and make migrations for them (pre_syncdb and post_syncdb deprecated)
- Initial_data fixtures are no longer loaded for apps with migrations
- Applications can run code at startup, before Django does anything else, with the ready() method of their configuration.
- Application labels are assigned correctly to models even when they’re defined outside of models.py.
- Possibility to omit models.py entirely if an application doesn’t have any models
- Applications can be relabeled with the label attribute of application configurations, to work around label conflicts.
- Ability to customize application name in the admin with the verbose_name of application configuration
- The admin automatically calls autodiscover() when Django starts. You can consequently remove this line from your URLconf.
- Django imports all application configurations and models as soon as it starts, through a deterministic and straightforward process.
Django 1.7 includes a new method – deconstruct(), which accepts no agruments. However, the method returns a tuple of four items
name: The field’s attribute name on its parent model, or None if it is not part of a model
path: A dotted, Python path to the class of this field, including the class name.
args: Positional arguments, as a list
kwargs: Keyword arguments, as a dict
The other core features of Django 1.7 are as follows
- New system check framework
- New Prefetch object for advanced prefetch_related operations
- Admin shortcuts support time zones
- Using database cursors as context managers
- Custom lookups
- Improvements to Form error handling (Form.add_error(), Error metadata and Error containers and backward compatibility)
The Django 1.7 release notes also provide a list all new features added to django.contrib.admin, django.contrib.auth, django.contrib.formtools, django.contrib.gis, django.contrib.messages, django.contrib.redirects, django.contrib.sessions, django.contrib.sitemaps, django.contrib.sites, django.contrib.staticfiles, django.contrib.syndication,
Django 1.7 also added improvements to cache, Cross Site Request Forgery, Email, File Storage, File Uploads, Forms, Internationalization, Management Commands, Models, Signals, Templates, Requests, Responses, Tests, Utilities and validators. The release notes also provide backwards incompatible changes in version 1.7.
Django 1.7 requires Python 2.7 or above. Moreover, support for Python 2.6 has been dropped and Python 3.4 has been added.
“This change should affect only a small number of Django users, as most operating-system vendors today are shipping Python 2.7 or newer as their default version”, mentions Django 1.7 release note.
If you are still using Python 2.6, you will be required to make use of Django 1.6 until you can upgrade your Python version. As per Django support policy, version 1.6 will continue to receive security support until the release of Django 1.8.