Welcome to Django 1.0!
\nWe’ve been looking forward to this moment for over three years, and it’s\nfinally here. Django 1.0 represents the largest milestone in Django’s\ndevelopment to date: a web framework that a group of perfectionists can truly\nbe proud of.
\nDjango 1.0 represents over three years of community development as an Open\nSource project. Django’s received contributions from hundreds of developers,\nbeen translated into fifty languages, and today is used by developers on every\ncontinent and in every kind of job.
\nAn interesting historical note: when Django was first released in July 2005,\nthe initial released version of Django came from an internal repository at\nrevision number 8825. Django 1.0 represents revision 8961 of our public\nrepository. It seems fitting that our 1.0 release comes at the moment where\ncommunity contributions overtake those made privately.
\nThe release of Django 1.0 comes with a promise of API\nstability and forwards-compatibility. In a nutshell, this means that code you\ndevelop against Django 1.0 will continue to work against 1.1 unchanged, and you\nshould need to make only minor changes for any 1.X release.
\nSee the API stability guide for full details.
\nDjango 1.0 has a number of backwards-incompatible changes from Django 0.96. If\nyou have apps written against Django 0.96 that you need to port, see our\ndetailed porting guide:
\n\nA complete list of backwards-incompatible changes can be found at\nhttps://code.djangoproject.com/wiki/BackwardsIncompatibleChanges.
\nA lot!
\nSince Django 0.96, we’ve made over 4,000 code commits, fixed more than 2,000\nbugs, and edited, added, or removed around 350,000 lines of code. We’ve also\nadded 40,000 lines of new documentation, and greatly improved what was already\nthere.
\nIn fact, new documentation is one of our favorite features of Django 1.0, so we\nmight as well start there. First, there’s a new documentation site:
\n\nThe documentation has been greatly improved, cleaned up, and generally made\nawesome. There’s now dedicated search, indexes, and more.
\nWe can’t possibly document everything that’s new in 1.0, but the documentation\nwill be your definitive guide. Anywhere you see something like:
\n\nYou’ll know that you’re looking at something new or changed.
\nThe other major highlights of Django 1.0 are:
\nThe Django administrative interface (django.contrib.admin) has been\ncompletely refactored; admin definitions are now completely decoupled from\nmodel definitions (no more class Admin declaration in models!), rewritten\nto use Django’s new form-handling library (introduced in the 0.96 release as\ndjango.newforms, and now available as simply django.forms) and\nredesigned with extensibility and customization in mind. Full documentation for\nthe admin application is available online in the official Django documentation:
See the admin reference for details
\nDjango’s internals have been refactored to use Unicode throughout; this\ndrastically simplifies the task of dealing with non-Western-European content\nand data in Django. Additionally, utility functions have been provided to ease\ninteroperability with third-party libraries and systems which may or may not\nhandle Unicode gracefully. Details are available in Django’s Unicode-handling\ndocumentation.
\nSee Unicode data.
\nDjango’s object-relational mapper – the component which provides the mapping\nbetween Django model classes and your database, and which mediates your\ndatabase queries – has been dramatically improved by a massive refactoring.\nFor most users of Django this is backwards-compatible; the public-facing API\nfor database querying underwent a few minor changes, but most of the updates\ntook place in the ORM’s internals. A guide to the changes, including\nbackwards-incompatible modifications and mentions of new features opened up by\nthis refactoring, is available on the Django wiki.
\nTo provide improved security against cross-site scripting (XSS)\nvulnerabilities, Django’s template system now automatically escapes the output\nof variables. This behavior is configurable, and allows both variables and\nlarger template constructs to be marked as safe (requiring no escaping) or\nunsafe (requiring escaping). A full guide to this feature is in the\ndocumentation for the\nautoescape tag.
django.contrib.gis (GeoDjango)Link to this heading#A project over a year in the making, this adds world-class GIS (Geographic\nInformation Systems) support to Django, in the form of a contrib\napplication. Its documentation is currently being maintained externally, and\nwill be merged into the main Django documentation shortly. Huge thanks go to\nJustin Bronn, Jeremy Dunck, Brett Hoerner and Travis Pinney for their efforts\nin creating and completing this feature.
See GeoDjango for details.
\nDjango’s built-in FileField and ImageField now can take advantage of\npluggable file-storage backends, allowing extensive customization of where and\nhow uploaded files get stored by Django. For details, see the files\ndocumentation; big thanks go to Marty Alchin for putting in\nthe hard work to get this completed.
Thanks to a lot of work from Leo Soto during a Google Summer of Code project,\nDjango’s codebase has been refactored to remove incompatibilities with\nJython, an implementation of Python written in Java, which runs Python code\non the Java Virtual Machine. Django is now compatible with the forthcoming\nJython 2.5 release.
\nClasses are now included in django.contrib.contenttypes which can be used\nto support generic relations in both the admin interface and in end-user forms.\nSee the documentation for generic relations for\ndetails.
INSERT/UPDATE distinctionLink to this heading#Although Django’s default behavior of having a model’s save() method\nautomatically determine whether to perform an INSERT or an UPDATE at\nthe SQL level is suitable for the majority of cases, there are occasional\nsituations where forcing one or the other is useful. As a result, models can\nnow support an additional parameter to save() which can force a specific\noperation.
See Forcing an INSERT or UPDATE for details.
\nCacheMiddlewareLink to this heading#Django’s CacheMiddleware has been split into three classes:\nCacheMiddleware itself still exists and retains all of its previous\nfunctionality, but it is now built from two separate middleware classes which\nhandle the two parts of caching (inserting into and reading from the cache)\nseparately, offering additional flexibility for situations where combining\nthese functions into a single middleware posed problems.
Full details, including updated notes on appropriate use, are in the\ncaching documentation.
\ndjango.contrib.commentsLink to this heading#As part of a Google Summer of Code project, Thejaswi Puthraya carried out a\nmajor rewrite and refactoring of Django’s bundled comment system, greatly\nincreasing its flexibility and customizability.
\nA number of features and methods which had previously been marked as\ndeprecated, and which were scheduled for removal prior to the 1.0 release, are\nno longer present in Django. These include imports of the form library from\ndjango.newforms (now located simply at django.forms), the\nform_for_model and form_for_instance helper functions (which have been\nreplaced by ModelForm) and a number of deprecated features which were\nreplaced by the dispatcher, file-uploading and file-storage refactoring\nintroduced in the Django 1.0 alpha releases.
We’ve done our best to make Django 1.0 as solid as possible, but unfortunately\nthere are a couple of issues that we know about in the release.
\nto_fieldLink to this heading#If you’re using multiple table model inheritance, be aware of this caveat: child models using a\ncustom parent_link and to_field will cause database integrity errors. A\nset of models like the following are not valid:
class Parent(models.Model):\n name = models.CharField(max_length=10)\n other_value = models.IntegerField(unique=True)\n\n\nclass Child(Parent):\n father = models.OneToOneField(\n Parent, primary_key=True, to_field="other_value", parent_link=True\n )\n value = models.IntegerField()\nThis bug will be fixed in the next release of Django.
\nDjango attempts to support as many features as possible on all database\nbackends. However, not all database backends are alike, and in particular many\nof the supported database differ greatly from version to version. It’s a good\nidea to checkout our notes on supported database:
\n\n