"Fossies" - the Fresh Open Source Software Archive

Member "Django-1.11.25/docs/releases/1.0.txt" (1 Oct 2019, 10176 Bytes) of package /linux/www/Django-1.11.25.tar.gz:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 ========================
    2 Django 1.0 release notes
    3 ========================
    5 Welcome to Django 1.0!
    7 We've been looking forward to this moment for over three years, and it's finally
    8 here. Django 1.0 represents the largest milestone in Django's development to
    9 date: a Web framework that a group of perfectionists can truly be proud of.
   11 Django 1.0 represents over three years of community development as an Open
   12 Source project. Django's received contributions from hundreds of developers,
   13 been translated into fifty languages, and today is used by developers on every
   14 continent and in every kind of job.
   16 An interesting historical note: when Django was first released in July 2005, the
   17 initial released version of Django came from an internal repository at revision
   18 number 8825. Django 1.0 represents revision 8961 of our public repository. It
   19 seems fitting that our 1.0 release comes at the moment where community
   20 contributions overtake those made privately.
   22 Stability and forwards-compatibility
   23 ====================================
   25 The release of Django 1.0 comes with a promise of API
   26 stability and forwards-compatibility. In a nutshell, this means that code you
   27 develop against Django 1.0 will continue to work against 1.1 unchanged, and you
   28 should need to make only minor changes for any 1.X release.
   30 See the :doc:`API stability guide </misc/api-stability>` for full details.
   32 Backwards-incompatible changes
   33 ==============================
   35 Django 1.0 has a number of backwards-incompatible changes from Django 0.96. If
   36 you have apps written against Django 0.96 that you need to port, see our
   37 detailed porting guide:
   39 .. toctree::
   40    :maxdepth: 1
   42    1.0-porting-guide
   44 A complete list of backwards-incompatible changes can be found at
   45 https://code.djangoproject.com/wiki/BackwardsIncompatibleChanges.
   47 What's new in Django 1.0
   48 ========================
   50 A *lot*!
   52 Since Django 0.96, we've made over 4,000 code commits, fixed more than 2,000
   53 bugs, and edited, added, or removed around 350,000 lines of code. We've also
   54 added 40,000 lines of new documentation, and greatly improved what was already
   55 there.
   57 In fact, new documentation is one of our favorite features of Django 1.0, so we
   58 might as well start there. First, there's a new documentation site:
   60 * https://docs.djangoproject.com/
   62 The documentation has been greatly improved, cleaned up, and generally made
   63 awesome. There's now dedicated search, indexes, and more.
   65 We can't possibly document everything that's new in 1.0, but the documentation
   66 will be your definitive guide. Anywhere you see something like:
   68 .. versionadded:: 1.0
   70    This feature is new in Django 1.0
   72 You'll know that you're looking at something new or changed.
   74 The other major highlights of Django 1.0 are:
   76 Re-factored admin application
   77 -----------------------------
   79 The Django administrative interface (``django.contrib.admin``) has been
   80 completely refactored; admin definitions are now completely decoupled from model
   81 definitions (no more ``class Admin`` declaration in models!), rewritten to use
   82 Django's new form-handling library (introduced in the 0.96 release as
   83 ``django.newforms``, and now available as simply ``django.forms``) and
   84 redesigned with extensibility and customization in mind. Full documentation for
   85 the admin application is available online in the official Django documentation:
   87 See the :doc:`admin reference </ref/contrib/admin/index>` for details
   89 Improved Unicode handling
   90 -------------------------
   92 Django's internals have been refactored to use Unicode throughout; this
   93 drastically simplifies the task of dealing with non-Western-European content and
   94 data in Django. Additionally, utility functions have been provided to ease
   95 interoperability with third-party libraries and systems which may or may not
   96 handle Unicode gracefully. Details are available in Django's Unicode-handling
   97 documentation.
   99 See :doc:`/ref/unicode`.
  101 An improved ORM
  102 ---------------
  104 Django's object-relational mapper -- the component which provides the mapping
  105 between Django model classes and your database, and which mediates your database
  106 queries -- has been dramatically improved by a massive refactoring. For most
  107 users of Django this is backwards-compatible; the public-facing API for database
  108 querying underwent a few minor changes, but most of the updates took place in
  109 the ORM's internals. A guide to the changes, including backwards-incompatible
  110 modifications and mentions of new features opened up by this refactoring, is
  111 `available on the Django wiki`__.
  113 __ https://code.djangoproject.com/wiki/QuerysetRefactorBranch
  115 Automatic escaping of template variables
  116 ----------------------------------------
  118 To provide improved security against cross-site scripting (XSS) vulnerabilities,
  119 Django's template system now automatically escapes the output of variables. This
  120 behavior is configurable, and allows both variables and larger template
  121 constructs to be marked as safe (requiring no escaping) or unsafe (requiring
  122 escaping). A full guide to this feature is in the documentation for the
  123 :ttag:`autoescape` tag.
  125 ``django.contrib.gis`` (GeoDjango)
  126 ----------------------------------
  128 A project over a year in the making, this adds world-class GIS (`Geographic
  129 Information Systems`_) support to Django, in the form of a ``contrib``
  130 application. Its documentation is currently being maintained externally, and
  131 will be merged into the main Django documentation shortly. Huge thanks go to
  132 Justin Bronn, Jeremy Dunck, Brett Hoerner and Travis Pinney for their efforts in
  133 creating and completing this feature.
  135 See http://geodjango.org/ for details.
  137 .. _Geographic Information Systems: https://en.wikipedia.org/wiki/Geographic_information_system
  139 Pluggable file storage
  140 ----------------------
  142 Django's built-in ``FileField`` and ``ImageField`` now can take advantage of
  143 pluggable file-storage backends, allowing extensive customization of where and
  144 how uploaded files get stored by Django. For details, see :doc:`the files
  145 documentation </topics/files>`; big thanks go to Marty Alchin for putting in the
  146 hard work to get this completed.
  148 Jython compatibility
  149 --------------------
  151 Thanks to a lot of work from Leo Soto during a Google Summer of Code project,
  152 Django's codebase has been refactored to remove incompatibilities with
  153 `Jython`_, an implementation of Python written in Java, which runs Python code
  154 on the Java Virtual Machine. Django is now compatible with the forthcoming
  155 Jython 2.5 release.
  157 See :doc:`/howto/jython`.
  159 .. _Jython: http://www.jython.org/
  161 Generic relations in forms and admin
  162 ------------------------------------
  164 Classes are now included in ``django.contrib.contenttypes`` which can be used to
  165 support generic relations in both the admin interface and in end-user forms. See
  166 :ref:`the documentation for generic relations <generic-relations>` for details.
  168 ``INSERT``/``UPDATE`` distinction
  169 ---------------------------------
  171 Although Django's default behavior of having a model's ``save()`` method
  172 automatically determine whether to perform an ``INSERT`` or an ``UPDATE`` at the
  173 SQL level is suitable for the majority of cases, there are occasional situations
  174 where forcing one or the other is useful. As a result, models can now support an
  175 additional parameter to ``save()`` which can force a specific operation.
  177 See :ref:`ref-models-force-insert` for details.
  179 Split ``CacheMiddleware``
  180 -------------------------
  182 Django's ``CacheMiddleware`` has been split into three classes:
  183 ``CacheMiddleware`` itself still exists and retains all of its previous
  184 functionality, but it is now built from two separate middleware classes which
  185 handle the two parts of caching (inserting into and reading from the cache)
  186 separately, offering additional flexibility for situations where combining these
  187 functions into a single middleware posed problems.
  189 Full details, including updated notes on appropriate use, are in :doc:`the
  190 caching documentation </topics/cache>`.
  192 Refactored ``django.contrib.comments``
  193 --------------------------------------
  195 As part of a Google Summer of Code project, Thejaswi Puthraya carried out a
  196 major rewrite and refactoring of Django's bundled comment system, greatly
  197 increasing its flexibility and customizability.
  199 Removal of deprecated features
  200 ------------------------------
  202 A number of features and methods which had previously been marked as deprecated,
  203 and which were scheduled for removal prior to the 1.0 release, are no longer
  204 present in Django. These include imports of the form library from
  205 ``django.newforms`` (now located simply at ``django.forms``), the
  206 ``form_for_model`` and ``form_for_instance`` helper functions (which have been
  207 replaced by ``ModelForm``) and a number of deprecated features which were
  208 replaced by the dispatcher, file-uploading and file-storage refactorings
  209 introduced in the Django 1.0 alpha releases.
  211 Known issues
  212 ============
  214 We've done our best to make Django 1.0 as solid as possible, but unfortunately
  215 there are a couple of issues that we know about in the release.
  217 Multi-table model inheritance with ``to_field``
  218 -----------------------------------------------
  220 If you're using :ref:`multiple table model inheritance
  221 <multi-table-inheritance>`, be aware of this caveat: child models using a custom
  222 ``parent_link`` and ``to_field`` will cause database integrity errors. A set of
  223 models like the following are **not valid**::
  225     class Parent(models.Model):
  226         name = models.CharField(max_length=10)
  227         other_value = models.IntegerField(unique=True)
  229     class Child(Parent):
  230         father = models.OneToOneField(Parent, primary_key=True, to_field="other_value", parent_link=True)
  231         value = models.IntegerField()
  233 This bug will be fixed in the next release of Django.
  235 Caveats with support of certain databases
  236 -----------------------------------------
  238 Django attempts to support as many features as possible on all database
  239 backends. However, not all database backends are alike, and in particular many of the supported database differ greatly from version to version. It's a good idea to checkout our :doc:`notes on supported database </ref/databases>`:
  241 - :ref:`mysql-notes`
  242 - :ref:`sqlite-notes`
  243 - :ref:`oracle-notes`