|Version 10 (modified by 12 years ago) (diff),|
As Django is still in pre-release mode, we haven't yet committed to maintaining backwards compatibility in any APIs. Although we're keeping such changes to a minimum, Django developers should be acutely aware of these changes.
Of course, once we reach our first official release, we'll be strongly committed to backward compatibility.
This page lists all backwards-incompatible changes to Django so far.
Moved mod_python handler
As of , using
django.core.handler as a mod_python handler is deprecated. Use
django.core.handlers.modpython instead. We will be removing
django.core.handler for Django's first release.
Changed ordering syntax
As of , syntax used for
order_by (in the database API) and
ordering (in models) has changed.
Example of old ordering syntax:
order_by=[('foo', 'ASC'), ('bar', 'DESC')]
Example of new ordering syntax:
The old syntax is deprecated, and we'll stop supporting it for Django's first release.
As of ,
django/core/meta.py has been converted to a package,
django/core/meta/. If you're using a version of Django from before , make sure to delete
django/core/meta.pyo, if they exist. The existence of those files doesn't pose any known problems, but it's best to clean things up.
Changed edit_inline and edit_inline_type behavior
As of , using
edit_inline_type in your models is deprecated, in favor of a less-redundant approach that uses
Example of old syntax:
Example of new syntax:
We'll stop supporting the old syntax for Django's first release.
Changed admin log to store primary keys as TEXT fields, not INTEGER fields
As of , the
object_id field in
django.models.auth.LogEntry is a
TextField instead of an
IntegerField. We made this change to accomodate non-integer primary keys.
If you're using a Django database installation from before  and you want to use non-integer primary keys on an object you edit in the admin site, you'll need to do an
ALTER TABLE in your database.
BEGIN; ALTER TABLE auth_admin_log RENAME object_id TO object_id_old; ALTER TABLE auth_admin_log ADD COLUMN object_id TEXT; UPDATE auth_admin_log SET object_id = object_id_old; ALTER TABLE auth_admin_log DROP COLUMN object_id_old; COMMIT;
ALTER TABLE auth_admin_log MODIFY object_id TEXT;
Added support for anonymous sessions
As of , Django has support for anonymous sessions. If you're using a Django database installation from before  and you want to use the Django admin, anonymous sessions or auth-based sessions, you'll need to make a few updates to your database and settings files.
Change your settings files
"django.middleware.sessions.SessionMiddleware" to the
MIDDLEWARE_CLASSES tuple in your admin settings file. Make sure it appears before
"django.middleware.admin.AdminUserRequired". (The middleware classes are applied in order, and the admin middleware requires that the session middleware come first.)
If you want session support any other (i.e., non-admin) Django installation, change the
MIDDLEWARE_CLASSES setting accordingly. The order (i.e., whether it comes before or after the other installed middleware classes) doesn't matter.
Create the core_sessions database table
In PostgreSQL, use this:
CREATE TABLE core_sessions ( session_key varchar(40) NOT NULL PRIMARY KEY, session_data text NOT NULL, expire_date timestamp with time zone NOT NULL ); INSERT INTO content_types (name, package, python_module_name) VALUES ('session', 'core', 'sessions');
In MySQL and SQLite, use this:
CREATE TABLE core_sessions ( session_key varchar(40) NOT NULL PRIMARY KEY, session_data text NOT NULL, expire_date datetime NOT NULL ); INSERT INTO content_types (name, package, python_module_name) VALUES ('session', 'core', 'sessions');
Remove old, unneeded things
Execute this SQL in your database:
DROP TABLE auth_sessions; DELETE FROM content_types WHERE package = 'auth' AND python_module_name = 'sessions';
Edit your settings file(s) to remove
REGISTRATION_COOKIE_DOMAIN, if they exist.