May 17, 2010.
\nWelcome to Django 1.2!
\nNearly a year in the making, Django 1.2 packs an impressive list of new\nfeatures and lots of bug fixes. These release notes cover\nthe new features, as well as important changes you’ll want to be aware of when\nupgrading from Django 1.1 or older versions.
\nDjango 1.2 introduces several large, important new features, including:
\nSupport for multiple database connections in a single Django instance.
Model validation inspired by Django’s form validation.
Vastly improved protection against Cross-Site Request Forgery (CSRF).
A new user “messages” framework with support for\ncookie- and session-based message for both anonymous and authenticated users.
Hooks for object-level permissions, permissions for anonymous users,\nand more flexible username requirements.
Customization of email sending via email backends.
New “smart” if template tag which supports\ncomparison operators.
These are just the highlights; full details and a complete list of features\nmay be found below.
\n\nWherever possible these features have been introduced in a backwards-compatible\nmanner per our API stability policy policy.
\nHowever, a handful of features have changed in ways that, for some users,\nwill be backwards-incompatible. The big changes are:
\nSupport for Python 2.3 has been dropped. See the full notes\nbelow.
The new CSRF protection framework is not backwards-compatible with\nthe old system. Users of the old system will not be affected until\nthe old system is removed in Django 1.4.
\nHowever, upgrading to the new CSRF protection framework requires a few\nimportant backwards-incompatible changes, detailed in CSRF Protection,\nbelow.
\nAuthors of custom Field subclasses should be\naware that a number of methods have had a change in prototype, detailed\nunder get_db_prep_*() methods on Field, below.
The internals of template tags have changed somewhat; authors of custom\ntemplate tags that need to store state (e.g. custom control flow tags)\nshould ensure that their code follows the new rules for stateful template\ntags
The user_passes_test(),\nlogin_required(), and\npermission_required(), decorators\nfrom django.contrib.auth only apply to functions and no longer\nwork on methods. There’s a simple one-line fix detailed below.
Again, these are just the big features that will affect the most users. Users\nupgrading from previous versions of Django are heavily encouraged to consult\nthe complete list of backwards-incompatible changes and the list of deprecated\nfeatures.
\nWhile not a new feature, it’s important to note that Django 1.2\nintroduces the first shift in our Python compatibility policy since\nDjango’s initial public debut. Previous Django releases were tested\nand supported on 2.x Python versions from 2.3 up; Django 1.2, however,\ndrops official support for Python 2.3. As such, the minimum Python\nversion required for Django is now 2.4, and Django is tested and\nsupported on Python 2.4, 2.5 and 2.6, and will be supported on the\nas-yet-unreleased Python 2.7.
\nThis change should affect only a small number of Django users, as most\noperating-system vendors today are shipping Python 2.4 or newer as\ntheir default version. If you’re still using Python 2.3, however,\nyou’ll need to stick to Django 1.1 until you can upgrade; per\nour support policy, Django 1.1 will\ncontinue to receive security support until the release of Django 1.3.
\nA roadmap for Django’s overall 2.x Python support, and eventual\ntransition to Python 3.x, is currently being developed, and will be\nannounced prior to the release of Django 1.3.
\nDjango 1.2 adds the ability to use more than one database in your Django project. Queries can be issued at a\nspecific database with the using() method on QuerySet objects.\nIndividual objects can be saved to a specific database by providing a using\nargument when you call save().
Model instances now have support for validating their own data, and both model and form fields now accept configurable\nlists of validators specifying reusable, encapsulated\nvalidation behavior. Note, however, that validation must still be performed\nexplicitly. Simply invoking a model instance’s save() method will not\nperform any validation of the instance’s data.
Django now has much improved protection against Cross-Site Request\nForgery (CSRF) attacks. This type of attack occurs when a malicious\nwebsite contains a link, a form button or some JavaScript that is intended to\nperform some action on your website, using the credentials of a logged-in user\nwho visits the malicious site in their browser. A related type of attack,\n“login CSRF,” where an attacking site tricks a user’s browser into logging into\na site with someone else’s credentials, is also covered.
\nDjango now includes a robust and configurable messages framework with built-in support for cookie- and session-based\nmessaging, for both anonymous and authenticated clients. The messages framework\nreplaces the deprecated user message API and allows you to temporarily store\nmessages in one request and retrieve them for display in a subsequent request\n(usually the next one).
\nA foundation for specifying permissions at the per-object level has been added.\nAlthough there is no implementation of this in core, a custom authentication\nbackend can provide this implementation and it will be used by\ndjango.contrib.auth.models.User. See the authentication docs for more information.
If you provide a custom auth backend with supports_anonymous_user set to\nTrue, AnonymousUser will check the backend for permissions, just like\nUser already did. This is useful for centralizing permission handling - apps\ncan always delegate the question of whether something is allowed or not to\nthe authorization/authentication backend. See the authentication\ndocs for more details.
The built-in User model’s\nusername field now allows a wider\nrange of characters, including @, +, . and - characters.
You can now configure the way that Django sends email. Instead of using SMTP to send all email, you\ncan now choose a configurable email backend to send messages. If your\nhosting provider uses a sandbox or some other non-SMTP technique for\nsending mail, you can now construct an email backend that will allow\nDjango’s standard mail sending methods to use\nthose facilities.
\nThis also makes it easier to debug mail sending. Django ships with\nbackend implementations that allow you to send email to a\nfile, to the\nconsole, or to\nmemory. You can even configure all\nemail to be thrown away.
\nif tagLink to this heading#The if tag has been upgraded to be much more powerful. First, we’ve\nadded support for comparison operators. No longer will you have to type:
{% ifnotequal a b %}\n ...\n{% endifnotequal %}\nYou can now do this:
\n{% if a != b %}\n ...\n{% endif %}\nThere’s really no reason to use {% ifequal %} or {% ifnotequal %}\nanymore, unless you’re the nostalgic type.
The operators supported are ==, !=, <, >, <=, >=,\nin and not in, all of which work like the Python operators, in addition\nto and, or and not, which were already supported.
Also, filters may now be used in the if expression. For example:
<div\n {% if user.email|lower == message.recipient|lower %}\n class="highlight"\n {% endif %}\n>{{ message }}</div>\nIn previous versions of Django, every time you rendered a template, it\nwould be reloaded from disk. In Django 1.2, you can use a cached\ntemplate loader to load templates once, then\ncache the result for every subsequent render. This can lead to a\nsignificant performance improvement if your templates are broken into\nlots of smaller subtemplates (using the {% extends %} or {%\ninclude %} tags).
As a side effect, it is now much easier to support non-Django template\nlanguages.
\nAs part of the changes made to introduce Template caching and following\na general trend in Django, the template loaders API has been modified\nto use template loading mechanisms that are encapsulated in Python classes as\nopposed to functions, the only method available until Django 1.1.
\nAll the template loaders shipped with Django have\nbeen ported to the new API but they still implement the function-based API and\nthe template core machinery still accepts function-based loaders (builtin or\nthird party) so there is no immediate need to modify your TEMPLATE_LOADERS\nsetting in existing projects, things will keep working if you leave it\nuntouched up to and including the Django 1.3 release.
If you have developed your own custom template loaders we suggest to consider\nporting them to a class-based implementation because the code for backwards\ncompatibility with function-based loaders starts its deprecation process in\nDjango 1.2 and will be removed in Django 1.4. There is a description of the\nAPI these loader classes must implement in the template API reference and you\ncan also examine the source code of the loaders shipped with Django.
\nFixtures can now refer to remote objects using\nNatural keys. This lookup scheme is an\nalternative to the normal primary-key based object references in a\nfixture, improving readability and resolving problems referring to\nobjects whose primary key value may not be predictable or known.
\nBoth the test subcommand of django-admin.py and the\nruntests.py script used to run Django’s own test suite now support a\n--failfast option. When specified, this option causes the test runner to\nexit after encountering a failure instead of continuing with the test run. In\naddition, the handling of Ctrl-C during a test run has been improved to\ntrigger a graceful exit from the test run that reports details of the tests\nthat were run before the interruption.
BigIntegerFieldLink to this heading#Models can now use a 64-bit BigIntegerField type.
Django’s internationalization framework has been\nexpanded with locale-aware formatting and form processing. That means, if\nenabled, dates and numbers on templates will be displayed using the format\nspecified for the current locale. Django will also use localized formats when\nparsing data in forms. See Format localization for more details.
\nreadonly_fields in ModelAdminLink to this heading#django.contrib.admin.ModelAdmin.readonly_fields has been added to\nenable non-editable fields in add/change pages for models and inlines. Field\nand calculated values can be displayed alongside editable fields.
You can now use a DJANGO_COLORS environment variable to modify or\ndisable the colors used by django-admin.py to provide syntax\nhighlighting.
The most significant new feature for GeoDjango\nin 1.2 is support for multiple spatial databases. As a result,\nthe following spatial database backends\nare now included:
\ndjango.contrib.gis.db.backends.postgis
django.contrib.gis.db.backends.mysql
django.contrib.gis.db.backends.oracle
django.contrib.gis.db.backends.spatialite
GeoDjango now supports the rich capabilities added in the PostGIS 1.5 release.\nNew features include support for the geography type\nand enabling of distance queries\nwith non-point geometries on geographic coordinate systems.
\nSupport for 3D geometry fields was added, and may be enabled\nby setting the dim\nkeyword to 3 in your GeometryField.\nThe Extent3D aggregate\nand extent3d() GeoQuerySet method were added as a part of this feature.
The force_rhr(), reverse_geom(), and geohash() GeoQuerySet\nmethods are new.
The GEOS interface was updated to use thread-safe C library functions when\navailable on the platform.
\nThe GDAL interface now allows the user to set a\nspatial_filter on the features returned\nwhen iterating over a Layer.
Finally, GeoDjango’s documentation is now\nincluded with Django’s and is no longer hosted separately at geodjango.org.
now template tag format specifier characters: c and uLink to this heading#The argument to the now has gained two new format characters:\nc to specify that a datetime value should be formatted in ISO 8601\nformat, and u that allows output of the microseconds part of a\ndatetime or time value.
These are also available in others parts like the date and\ntime template filters, the humanize template tag library\nand the new format localization framework.
Wherever possible the new features above have been introduced in a\nbackwards-compatible manner per our API stability policy policy. This means that practically all existing\ncode which worked with Django 1.1 will continue to work with Django\n1.2; such code will, however, begin issuing warnings (see below for\ndetails).
\nHowever, a handful of features have changed in ways that, for some\nusers, will be immediately backwards-incompatible. Those changes are\ndetailed below.
\nWe’ve made large changes to the way CSRF protection works, detailed in\nthe CSRF documentation. Here are the major changes you\nshould be aware of:
\nCsrfResponseMiddleware and CsrfMiddleware have been deprecated and\nwill be removed completely in Django 1.4, in favor of a template tag that\nshould be inserted into forms.
All contrib apps use a csrf_protect decorator to protect the view. This\nrequires the use of the csrf_token template tag in the template. If you\nhave used custom templates for contrib views, you MUST READ THE UPGRADE\nINSTRUCTIONS to fix those templates.
CsrfViewMiddleware is included in MIDDLEWARE_CLASSES by\ndefault. This turns on CSRF protection by default, so views that accept\nPOST requests need to be written to work with the middleware. Instructions\non how to do this are found in the CSRF docs.
All of the CSRF has moved from contrib to core (with backwards\ncompatible imports in the old locations, which are deprecated and\nwill cease to be supported in Django 1.4).
get_db_prep_*() methods on FieldLink to this heading#Prior to Django 1.2, a custom Field had the option of defining\nseveral functions to support conversion of Python values into\ndatabase-compatible values. A custom field might look something like:
class CustomModelField(models.Field):\n ...\n\n def db_type(self): ...\n\n def get_db_prep_save(self, value): ...\n\n def get_db_prep_value(self, value): ...\n\n def get_db_prep_lookup(self, lookup_type, value): ...\nIn 1.2, these three methods have undergone a change in prototype, and\ntwo extra methods have been introduced:
\nclass CustomModelField(models.Field):\n ...\n\n def db_type(self, connection): ...\n\n def get_prep_value(self, value): ...\n\n def get_prep_lookup(self, lookup_type, value): ...\n\n def get_db_prep_save(self, value, connection): ...\n\n def get_db_prep_value(self, value, connection, prepared=False): ...\n\n def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False): ...\nThese changes are required to support multiple databases –\ndb_type and get_db_prep_* can no longer make any assumptions\nregarding the database for which it is preparing. The connection\nargument now provides the preparation methods with the specific\nconnection for which the value is being prepared.
The two new methods exist to differentiate general data-preparation\nrequirements from requirements that are database-specific. The\nprepared argument is used to indicate to the database-preparation\nmethods whether generic value preparation has been performed. If\nan unprepared (i.e., prepared=False) value is provided to the\nget_db_prep_*() calls, they should invoke the corresponding\nget_prep_*() calls to perform generic data preparation.
We’ve provided conversion functions that will transparently\nconvert functions adhering to the old prototype into functions\ncompatible with the new prototype. However, these conversion functions\nwill be removed in Django 1.4, so you should upgrade your Field\ndefinitions to use the new prototype as soon as possible.
If your get_db_prep_*() methods made no use of the database\nconnection, you should be able to upgrade by renaming\nget_db_prep_value() to get_prep_value() and\nget_db_prep_lookup() to get_prep_lookup(). If you require\ndatabase specific conversions, then you will need to provide an\nimplementation get_db_prep_* that uses the connection\nargument to resolve database-specific values.
user_passes_test, login_required and permission_requiredLink to this heading#django.contrib.auth.decorators provides the decorators\nlogin_required, permission_required and\nuser_passes_test. Previously it was possible to use these\ndecorators both on functions (where the first argument is ‘request’)\nand on methods (where the first argument is ‘self’, and the second\nargument is ‘request’). Unfortunately, flaws were discovered in the\ncode supporting this: it only works in limited circumstances, and\nproduces errors that are very difficult to debug when it does not\nwork.
For this reason, the ‘auto adapt’ behavior has been removed, and if\nyou are using these decorators on methods, you will need to manually\napply django.utils.decorators.method_decorator() to convert the\ndecorator to one that works with methods. For example, you would\nchange code from this:
class MyClass(object):\n @login_required\n def my_view(self, request):\n pass\nto this:
\nfrom django.utils.decorators import method_decorator\n\n\nclass MyClass(object):\n @method_decorator(login_required)\n def my_view(self, request):\n pass\nor:
\nfrom django.utils.decorators import method_decorator\n\nlogin_required_m = method_decorator(login_required)\n\n\nclass MyClass(object):\n @login_required_m\n def my_view(self, request):\n pass\nFor those of you who’ve been following the development trunk, this\nchange also applies to other decorators introduced since 1.1,\nincluding csrf_protect, cache_control and anything created\nusing decorator_from_middleware.
if tag changesLink to this heading#Due to new features in the if template tag, it no longer\naccepts ‘and’, ‘or’ and ‘not’ as valid variable names. Previously,\nthese strings could be used as variable names. Now, the keyword status\nis always enforced, and template code such as {% if not %} or {%\nif and %} will throw a TemplateSyntaxError. Also, in is a\nnew keyword and so is not a valid variable name in this tag.
LazyObjectLink to this heading#LazyObject is an undocumented-but-often-used utility class used for lazily\nwrapping other objects of unknown type.
In Django 1.1 and earlier, it handled introspection in a non-standard way,\ndepending on wrapped objects implementing a public method named\nget_all_members(). Since this could easily lead to name clashes, it has\nbeen changed to use the standard Python introspection method, involving\n__members__ and __dir__().
If you used LazyObject in your own code\nand implemented the get_all_members() method for wrapped objects, you’ll\nneed to make a couple of changes:
First, if your class does not have special requirements for introspection\n(i.e., you have not implemented __getattr__() or other methods that allow\nfor attributes not discoverable by normal mechanisms), you can simply remove\nthe get_all_members() method. The default implementation on LazyObject\nwill do the right thing.
If you have more complex requirements for introspection, first rename the\nget_all_members() method to __dir__(). This is the standard\nintrospection method for Python 2.6 and above. If you require support for\nPython versions earlier than 2.6, add the following code to the class:
__members__ = property(lambda self: self.__dir__())\n__dict__ on model instancesLink to this heading#Historically, the __dict__ attribute of a model instance has only contained\nattributes corresponding to the fields on a model.
In order to support multiple database configurations, Django 1.2 has\nadded a _state attribute to object instances. This attribute will\nappear in __dict__ for a model instance. If your code relies on\niterating over __dict__ to obtain a list of fields, you must now\nbe prepared to handle or filter out the _state attribute.
The exit status code of the test runners (tests/runtests.py and python\nmanage.py test) no longer represents the number of failed tests, because a\nfailure of 256 or more tests resulted in a wrong exit status code. The exit\nstatus code for the test runner is now 0 for success (no failing tests) and 1\nfor any number of test failures. If needed, the number of test failures can be\nfound at the end of the test runner’s output.
ModelForm.is_valid() and ModelForm.errorsLink to this heading#Much of the validation work for ModelForms has been moved down to the model\nlevel. As a result, the first time you call ModelForm.is_valid(), access\nModelForm.errors or otherwise trigger form validation, your model will be\ncleaned in-place. This conversion used to happen when the model was saved. If\nyou need an unmodified instance of your model, you should pass a copy to the\nModelForm constructor.
BooleanField on MySQLLink to this heading#In previous versions of Django, a model’s BooleanField under MySQL\nwould return its value as either 1 or 0, instead of True\nor False; for most people this wasn’t a problem because bool\nis a subclass of int in Python. In Django 1.2, however,\nBooleanField on MySQL correctly returns a real bool. The only\ntime this should ever be an issue is if you were expecting the\nrepr of a BooleanField to print 1 or 0.
max_num in FormSetsLink to this heading#As part of enhancements made to the handling of FormSets, the default\nvalue and interpretation of the max_num parameter to the\ndjango.forms.formsets.formset_factory() and\ndjango.forms.models.modelformset_factory() functions has changed slightly. This\nchange also affects the way the\nmax_num argument is used for\ninline admin objects.
Previously, the default value for max_num was 0 (zero).\nFormSets then used the boolean value of max_num to determine if a\nlimit was to be imposed on the number of generated forms. The default\nvalue of 0 meant that there was no default limit on the number of\nforms in a FormSet.
Starting with 1.2, the default value for max_num has been changed\nto None, and FormSets will differentiate between a value of\nNone and a value of 0. A value of None indicates that no\nlimit on the number of forms is to be imposed; a value of 0\nindicates that a maximum of 0 forms should be imposed. This doesn’t\nnecessarily mean that no forms will be displayed – see the\nModelFormSet documentation for more\ndetails.
If you were manually specifying a value of 0 for max_num, you\nwill need to update your FormSet and/or admin definitions.
email_reLink to this heading#An undocumented regular expression for validating email addresses has been\nmoved from django.form.fields to django.core.validators. You will need\nto update your imports if you are using it.
Finally, Django 1.2 deprecates some features from earlier releases.\nThese features are still supported, but will be gradually phased out\nover the next few release cycles.
\nCode taking advantage of any of the features below will raise a\nPendingDeprecationWarning in Django 1.2. This warning will be\nsilent by default, but may be turned on using Python’s warnings\nmodule, or by running Python with a -Wd or -Wall flag.
In Django 1.3, these warnings will become a DeprecationWarning,\nwhich is not silent. In Django 1.4 support for these features will\nbe removed entirely.
Prior to Django 1.2, Django used a number of settings to control\naccess to a single database. Django 1.2 introduces support for\nmultiple databases, and as a result the way you define database\nsettings has changed.
\nAny existing Django settings file will continue to work as expected\nuntil Django 1.4. Until then, old-style database settings will be\nautomatically translated to the new-style format.
\nIn the old-style (pre 1.2) format, you had a number of DATABASE_\nsettings in your settings file. For example:
DATABASE_NAME = "test_db"\nDATABASE_ENGINE = "postgresql_psycopg2"\nDATABASE_USER = "myusername"\nDATABASE_PASSWORD = "s3krit"\nThese settings are now in a dictionary named\nDATABASES. Each item in the dictionary corresponds to a\nsingle database connection, with the name 'default' describing the\ndefault database connection. The setting names have also been\nshortened. The previous sample settings would now look like this:
DATABASES = {\n "default": {\n "NAME": "test_db",\n "ENGINE": "django.db.backends.postgresql_psycopg2",\n "USER": "myusername",\n "PASSWORD": "s3krit",\n }\n}\nThis affects the following settings:
\nOld setting | \nNew Setting | \n
|---|---|
| \n\n |
| \n\n |
| \n\n |
| \n\n |
| \n\n |
| \n\n |
| \n\n |
| \n\n |
| \n\n |
| \n\n |
These changes are also required if you have manually created a database\nconnection using DatabaseWrapper() from your database backend of choice.
In addition to the change in structure, Django 1.2 removes the special\nhandling for the built-in database backends. All database backends\nmust now be specified by a fully qualified module name (i.e.,\ndjango.db.backends.postgresql_psycopg2, rather than just\npostgresql_psycopg2).
postgresql database backendLink to this heading#The psycopg1 library has not been updated since October 2005. As a\nresult, the postgresql database backend, which uses this library,\nhas been deprecated.
If you are currently using the postgresql backend, you should\nmigrate to using the postgresql_psycopg2 backend. To update your\ncode, install the psycopg2 library and change the\nENGINE setting to use\ndjango.db.backends.postgresql_psycopg2.
CsrfResponseMiddleware, the middleware that automatically inserted\nCSRF tokens into POST forms in outgoing pages, has been deprecated\nin favor of a template tag method (see above), and will be removed\ncompletely in Django 1.4. CsrfMiddleware, which includes the\nfunctionality of CsrfResponseMiddleware and\nCsrfViewMiddleware, has likewise been deprecated.
Also, the CSRF module has moved from contrib to core, and the old\nimports are deprecated, as described in the upgrading notes.
\n\nSMTPConnectionLink to this heading#The SMTPConnection class has been deprecated in favor of a generic\nemail backend API. Old code that explicitly instantiated an instance\nof an SMTPConnection:
from django.core.mail import SMTPConnection\n\nconnection = SMTPConnection()\nmessages = get_notification_email()\nconnection.send_messages(messages)\n…should now call get_connection() to\ninstantiate a generic email connection:
from django.core.mail import get_connection\n\nconnection = get_connection()\nmessages = get_notification_email()\nconnection.send_messages(messages)\nDepending on the value of the EMAIL_BACKEND setting, this\nmay not return an SMTP connection. If you explicitly require an SMTP\nconnection with which to send email, you can explicitly request an\nSMTP connection:
from django.core.mail import get_connection\n\nconnection = get_connection("django.core.mail.backends.smtp.EmailBackend")\nmessages = get_notification_email()\nconnection.send_messages(messages)\nIf your call to construct an instance of SMTPConnection required\nadditional arguments, those arguments can be passed to the\nget_connection() call:
connection = get_connection(\n "django.core.mail.backends.smtp.EmailBackend", hostname="localhost", port=1234\n)\nThe API for storing messages in the user Message model (via\nuser.message_set.create) is now deprecated and will be removed in Django\n1.4 according to the standard\nrelease process.
To upgrade your code, you need to replace any instances of this:
\nuser.message_set.create("a message")\n…with the following:
\nfrom django.contrib import messages\n\nmessages.add_message(request, messages.INFO, "a message")\nAdditionally, if you make use of the method, you need to replace the\nfollowing:
\nfor message in user.get_and_delete_messages():\n ...\n…with:
\nfrom django.contrib import messages\n\nfor message in messages.get_messages(request):\n ...\nFor more information, see the full\nmessages documentation. You should begin to\nupdate your code to use the new API immediately.
\ndjango.utils.translation.get_date_formats() and\ndjango.utils.translation.get_partial_date_formats() have been deprecated\nin favor of the appropriate calls to django.utils.formats.get_format(),\nwhich is locale-aware when USE_L10N is set to True, and falls\nback to default settings if set to False.
To get the different date formats, instead of writing this:
\nfrom django.utils.translation import get_date_formats\n\ndate_format, datetime_format, time_format = get_date_formats()\n…use:
\nfrom django.utils import formats\n\ndate_format = formats.get_format("DATE_FORMAT")\ndatetime_format = formats.get_format("DATETIME_FORMAT")\ntime_format = formats.get_format("TIME_FORMAT")\nOr, when directly formatting a date value:
\nfrom django.utils import formats\n\nvalue_formatted = formats.date_format(value, "DATETIME_FORMAT")\nThe same applies to the globals found in django.forms.fields:
DEFAULT_DATE_INPUT_FORMATS
DEFAULT_TIME_INPUT_FORMATS
DEFAULT_DATETIME_INPUT_FORMATS
Use django.utils.formats.get_format() to get the appropriate formats.
Django 1.2 changes the test runner tools to use a class-based\napproach. Old style function-based test runners will still work, but\nshould be updated to use the new class-based runners.
\nUp to version 1.1 Django used technical message IDs\nto provide localizers the possibility to translate date and time formats. They\nwere translatable translation strings that could\nbe recognized because they were all upper case (for example\nDATETIME_FORMAT, DATE_FORMAT, TIME_FORMAT).\nThey have been deprecated in favor of the new Format localization\ninfrastructure that allows localizers to specify that information in a\nformats.py file in the corresponding django/conf/locale/<locale name>/\ndirectory.
To allow support for multiple databases, the GeoDjango database internals were\nchanged substantially. The largest backwards-incompatible change is that\nthe module django.contrib.gis.db.backend was renamed to\ndjango.contrib.gis.db.backends, where the full-fledged\nspatial database backends now exist. The\nfollowing sections provide information on the most-popular APIs that\nwere affected by these changes.
SpatialBackendLink to this heading#Prior to the creation of the separate spatial backends, the\ndjango.contrib.gis.db.backend.SpatialBackend object was\nprovided as an abstraction to introspect on the capabilities of\nthe spatial database. All of the attributes and routines provided by\nSpatialBackend are now a part of the ops attribute of the\ndatabase backend.
The old module django.contrib.gis.db.backend is still provided\nfor backwards-compatibility access to a SpatialBackend object,\nwhich is just an alias to the ops module of the\ndefault spatial database connection.
Users that were relying on undocumented modules and objects\nwithin django.contrib.gis.db.backend, rather the abstractions\nprovided by SpatialBackend, are required to modify their code.\nFor example, the following import which would work in 1.1 and\nbelow:
from django.contrib.gis.db.backend.postgis import PostGISAdaptor\nWould need to be changed:
\nfrom django.db import connection\n\nPostGISAdaptor = connection.ops.Adapter\nSpatialRefSys and GeometryColumns modelsLink to this heading#In previous versions of GeoDjango, django.contrib.gis.db.models\nhad SpatialRefSys and GeometryColumns models for querying\nthe OGC spatial metadata tables spatial_ref_sys and geometry_columns,\nrespectively.
While these aliases are still provided, they are only for the\ndefault database connection and exist only if the default connection\nis using a supported spatial database backend.
\n\nTo get the correct SpatialRefSys and GeometryColumns\nfor your spatial database use the methods provided by the spatial backend:
\n\n\n\n>>> from django.db import connections\n>>> SpatialRefSys = connections["my_spatialite"].ops.spatial_ref_sys()\n>>> GeometryColumns = connections["my_postgis"].ops.geometry_columns()\n
noLink to this heading#The currently used language code for Norwegian Bokmål no is being\nreplaced by the more common language code nb.
Django 1.2 changes the template loading mechanism to use a class-based\napproach. Old style function-based template loaders will still work, but should\nbe updated to use the new class-based template loaders.
\n