Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Added 1.5 beta release notes.

Backport of [7a62339] from master.
  • Loading branch information...
commit 28120a94364bae3c2aec3a530a2cebdac50ece2f 1 parent 5509eb8
Jacob Kaplan-Moss authored November 27, 2012
702  docs/releases/1.5-beta-1.txt
... ...
@@ -0,0 +1,702 @@
  1
+=============================
  2
+Django 1.5 beta release notes
  3
+=============================
  4
+
  5
+November 27, 2012.
  6
+
  7
+Welcome to Django 1.5 beta!
  8
+
  9
+This is the second in a series of preview/development releases leading
  10
+up to the eventual release of Django 1.5, scheduled for Decemeber
  11
+2012. This release is primarily targeted at developers who are
  12
+interested in trying out new features and testing the Django codebase
  13
+to help identify and resolve bugs prior to the final 1.5 release.
  14
+
  15
+As such, this release is *not* intended for production use, and any such use
  16
+is discouraged.
  17
+
  18
+These release notes cover the `new features`_, as well
  19
+as some `backwards incompatible changes`_ you'll want to be aware of
  20
+when upgrading from Django 1.4 or older versions. We've also dropped some
  21
+features, which are detailed in :doc:`our deprecation plan
  22
+</internals/deprecation>`, and we've `begun the deprecation process for some
  23
+features`_.
  24
+
  25
+.. _`new features`: `What's new in Django 1.5`_
  26
+.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.5`_
  27
+.. _`begun the deprecation process for some features`: `Features deprecated in 1.5`_
  28
+
  29
+Overview
  30
+========
  31
+
  32
+The biggest new feature in Django 1.5 is the `configurable User model`_. Before
  33
+Django 1.5, applications that wanted to use Django's auth framework
  34
+(:mod:`django.contrib.auth`) were forced to use Django's definition of a "user".
  35
+In Django 1.5, you can now swap out the ``User`` model for one that you write
  36
+yourself. This could be a simple extension to the existing ``User`` model -- for
  37
+example, you could add a Twitter or Facebook ID field -- or you could completely
  38
+replace the ``User`` with one totally customized for your site.
  39
+
  40
+Django 1.5 is also the first release with `Python 3 support`_! We're labeling
  41
+this support "experimental" because we don't yet consider it production-ready,
  42
+but everything's in place for you to start porting your apps to Python 3.
  43
+Our next release, Django 1.6, will support Python 3 without reservations.
  44
+
  45
+Other notable new features in Django 1.5 include:
  46
+
  47
+* `Support for saving a subset of model's fields`_ -
  48
+  :meth:`Model.save() <django.db.models.Model.save()>` now accepts an
  49
+  ``update_fields`` argument, letting you specify which fields are
  50
+  written back to the database when you call ``save()``. This can help
  51
+  in high-concurrency operations, and can improve performance.
  52
+
  53
+* Better `support for streaming responses <#explicit-streaming-responses-beta-1>`_ via
  54
+  the new  :class:`~django.http.StreamingHttpResponse` response class.
  55
+
  56
+* `GeoDjango`_ now supports PostGIS 2.0.
  57
+
  58
+* ... and more; `see below <#what-s-new-in-django-1-5>`_.
  59
+
  60
+Wherever possible we try to introduce new features in a backwards-compatible
  61
+manner per :doc:`our API stability policy </misc/api-stability>`.
  62
+However, as with previous releases, Django 1.5 ships with some minor
  63
+`backwards incompatible changes`_; people upgrading from previous versions
  64
+of Django should read that list carefully.
  65
+
  66
+One deprecated feature worth noting is the shift to "new-style" :ttag:`url` tag.
  67
+Prior to Django 1.3, syntax like ``{% url myview %}`` was interpreted
  68
+incorrectly (Django considered ``"myview"`` to be a literal name of a view, not
  69
+a template variable named ``myview``). Django 1.3 and above introduced the
  70
+``{% load url from future %}`` syntax to bring in the corrected behavior where
  71
+``myview`` was seen as a variable.
  72
+
  73
+The upshot of this is that if you are not using ``{% load url from future %}``
  74
+in your templates, you'll need to change tags like ``{% url myview %}`` to
  75
+``{% url "myview" %}``. If you *were* using ``{% load url from future %}`` you
  76
+can simply remove that line under Django 1.5
  77
+
  78
+Python compatibility
  79
+====================
  80
+
  81
+Django 1.5 requires Python 2.6.5 or above, though we **highly recommended**
  82
+Python 2.7.3 or above. Support for Python 2.5 and below as been dropped.
  83
+
  84
+This change should affect only a small number of Django users, as most
  85
+operating-system vendors today are shipping Python 2.6 or newer as their default
  86
+version. If you're still using Python 2.5, however, you'll need to stick to
  87
+Django 1.4 until you can upgrade your Python version. Per :doc:`our support
  88
+policy </internals/release-process>`, Django 1.4 will continue to receive
  89
+security support until the release of Django 1.6.
  90
+
  91
+Django 1.5 does not run on a Jython final release, because Jython's latest
  92
+release doesn't currently support Python 2.6. However, Jython currently does
  93
+offer an alpha release featuring 2.7 support, and Django 1.5 supports that alpha
  94
+release.
  95
+
  96
+Python 3 support
  97
+~~~~~~~~~~~~~~~~
  98
+
  99
+Django 1.5 introduces support for Python 3 - specifically, Python
  100
+3.2 and above. This comes in the form of a **single** codebase; you don't
  101
+need to install a different version of Django on Python 3. This means that
  102
+you can write application targeted for just Python 2, just Python 3, or single
  103
+applications that support both platforms.
  104
+
  105
+However, we're labeling this support "experimental" for now: although it's
  106
+received extensive testing via our automated test suite, it's received very
  107
+little real-world testing. We've done our best to eliminate bugs, but we can't
  108
+be sure we covered all possible uses of Django. Further, Django's more than a
  109
+web framework; it's an ecosystem of pluggable components. At this point, very
  110
+few third-party applications have been ported to Python 3, so it's unlikely
  111
+that a real-world application will have all its dependencies satisfied under
  112
+Python 3.
  113
+
  114
+Thus, we're recommending that Django 1.5 not be used in production under Python
  115
+3. Instead, use this opportunity to begin :doc:`porting applications to Python 3
  116
+</topics/python3>`. If you're an author of a pluggable component, we encourage you
  117
+to start porting now.
  118
+
  119
+We plan to offer first-class, production-ready support for Python 3 in our next
  120
+release, Django 1.6.
  121
+
  122
+What's new in Django 1.5
  123
+========================
  124
+
  125
+Configurable User model
  126
+~~~~~~~~~~~~~~~~~~~~~~~
  127
+
  128
+In Django 1.5, you can now use your own model as the store for user-related
  129
+data. If your project needs a username with more than 30 characters, or if
  130
+you want to store user's names in a format other than first name/last name,
  131
+or you want to put custom profile information onto your User object, you can
  132
+now do so.
  133
+
  134
+If you have a third-party reusable application that references the User model,
  135
+you may need to make some changes to the way you reference User instances. You
  136
+should also document any specific features of the User model that your
  137
+application relies upon.
  138
+
  139
+See the :ref:`documentation on custom User models <auth-custom-user>` for
  140
+more details.
  141
+
  142
+Support for saving a subset of model's fields
  143
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  144
+
  145
+The method :meth:`Model.save() <django.db.models.Model.save()>` has a new
  146
+keyword argument ``update_fields``. By using this argument it is possible to
  147
+save only a select list of model's fields. This can be useful for performance
  148
+reasons or when trying to avoid overwriting concurrent changes.
  149
+
  150
+Deferred instances (those loaded by .only() or .defer()) will automatically
  151
+save just the loaded fields. If any field is set manually after load, that
  152
+field will also get updated on save.
  153
+
  154
+See the :meth:`Model.save() <django.db.models.Model.save()>` documentation for
  155
+more details.
  156
+
  157
+Caching of related model instances
  158
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  159
+
  160
+When traversing relations, the ORM will avoid re-fetching objects that were
  161
+previously loaded. For example, with the tutorial's models::
  162
+
  163
+    >>> first_poll = Poll.objects.all()[0]
  164
+    >>> first_choice = first_poll.choice_set.all()[0]
  165
+    >>> first_choice.poll is first_poll
  166
+    True
  167
+
  168
+In Django 1.5, the third line no longer triggers a new SQL query to fetch
  169
+``first_choice.poll``; it was set by the second line.
  170
+
  171
+For one-to-one relationships, both sides can be cached. For many-to-one
  172
+relationships, only the single side of the relationship can be cached. This
  173
+is particularly helpful in combination with ``prefetch_related``.
  174
+
  175
+.. _explicit-streaming-responses-beta-1:
  176
+
  177
+Explicit support for streaming responses
  178
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  179
+
  180
+Before Django 1.5, it was possible to create a streaming response by passing
  181
+an iterator to :class:`~django.http.HttpResponse`. But this was unreliable:
  182
+any middleware that accessed the :attr:`~django.http.HttpResponse.content`
  183
+attribute would consume the iterator prematurely.
  184
+
  185
+You can now explicitly generate a streaming response with the new
  186
+:class:`~django.http.StreamingHttpResponse` class. This class exposes a
  187
+:class:`~django.http.StreamingHttpResponse.streaming_content` attribute which
  188
+is an iterator.
  189
+
  190
+Since :class:`~django.http.StreamingHttpResponse` does not have a ``content``
  191
+attribute, middleware that needs access to the response content must test for
  192
+streaming responses and behave accordingly. See :ref:`response-middleware` for
  193
+more information.
  194
+
  195
+``{% verbatim %}`` template tag
  196
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  197
+
  198
+To make it easier to deal with javascript templates which collide with Django's
  199
+syntax, you can now use the :ttag:`verbatim` block tag to avoid parsing the
  200
+tag's content.
  201
+
  202
+Retrieval of ``ContentType`` instances associated with proxy models
  203
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  204
+
  205
+The methods :meth:`ContentTypeManager.get_for_model() <django.contrib.contenttypes.models.ContentTypeManager.get_for_model()>`
  206
+and :meth:`ContentTypeManager.get_for_models() <django.contrib.contenttypes.models.ContentTypeManager.get_for_models()>`
  207
+have a new keyword argument – respectively ``for_concrete_model`` and ``for_concrete_models``.
  208
+By passing ``False`` using this argument it is now possible to retrieve the
  209
+:class:`ContentType <django.contrib.contenttypes.models.ContentType>`
  210
+associated with proxy models.
  211
+
  212
+New ``view`` variable in class-based views context
  213
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  214
+
  215
+In all :doc:`generic class-based views </topics/class-based-views/index>`
  216
+(or any class-based view inheriting from ``ContextMixin``), the context dictionary
  217
+contains a ``view`` variable that points to the ``View`` instance.
  218
+
  219
+GeoDjango
  220
+~~~~~~~~~
  221
+
  222
+* :class:`~django.contrib.gis.geos.LineString` and
  223
+  :class:`~django.contrib.gis.geos.MultiLineString` GEOS objects now support the
  224
+  :meth:`~django.contrib.gis.geos.GEOSGeometry.interpolate()` and
  225
+  :meth:`~django.contrib.gis.geos.GEOSGeometry.project()` methods
  226
+  (so-called linear referencing).
  227
+
  228
+* The wkb and hex properties of `GEOSGeometry` objects preserve the Z dimension.
  229
+
  230
+* Support for PostGIS 2.0 has been added and support for GDAL < 1.5 has been
  231
+  dropped.
  232
+
  233
+Minor features
  234
+~~~~~~~~~~~~~~
  235
+
  236
+Django 1.5 also includes several smaller improvements worth noting:
  237
+
  238
+* The template engine now interprets ``True``, ``False`` and ``None`` as the
  239
+  corresponding Python objects.
  240
+
  241
+* :mod:`django.utils.timezone` provides a helper for converting aware
  242
+  datetimes between time zones. See :func:`~django.utils.timezone.localtime`.
  243
+
  244
+* The generic views support OPTIONS requests.
  245
+
  246
+* Management commands do not raise ``SystemExit`` any more when called by code
  247
+  from :ref:`call_command <call-command>`. Any exception raised by the command
  248
+  (mostly :ref:`CommandError <ref-command-exceptions>`) is propagated.
  249
+
  250
+* The dumpdata management command outputs one row at a time, preventing
  251
+  out-of-memory errors when dumping large datasets.
  252
+
  253
+* In the localflavor for Canada, "pq" was added to the acceptable codes for
  254
+  Quebec. It's an old abbreviation.
  255
+
  256
+* The :ref:`receiver <connecting-receiver-functions>` decorator is now able to
  257
+  connect to more than one signal by supplying a list of signals.
  258
+
  259
+* In the admin, you can now filter users by groups which they are members of.
  260
+
  261
+* :meth:`QuerySet.bulk_create()
  262
+  <django.db.models.query.QuerySet.bulk_create>` now has a batch_size
  263
+  argument. By default the batch_size is unlimited except for SQLite where
  264
+  single batch is limited so that 999 parameters per query isn't exceeded.
  265
+
  266
+* The :setting:`LOGIN_URL` and :setting:`LOGIN_REDIRECT_URL` settings now also
  267
+  accept view function names and
  268
+  :ref:`named URL patterns <naming-url-patterns>`. This allows you to reduce
  269
+  configuration duplication. More information can be found in the
  270
+  :func:`~django.contrib.auth.decorators.login_required` documentation.
  271
+
  272
+* Django now provides a mod_wsgi :doc:`auth handler
  273
+  </howto/deployment/wsgi/apache-auth>`.
  274
+
  275
+* The :meth:`QuerySet.delete() <django.db.models.query.QuerySet.delete>`
  276
+  and :meth:`Model.delete() <django.db.models.Model.delete()>` can now take
  277
+  fast-path in some cases. The fast-path allows for less queries and less
  278
+  objects fetched into memory. See :meth:`QuerySet.delete()
  279
+  <django.db.models.query.QuerySet.delete>` for details.
  280
+
  281
+* An instance of :class:`~django.core.urlresolvers.ResolverMatch` is stored on
  282
+  the request as ``resolver_match``.
  283
+
  284
+* By default, all logging messages reaching the `django` logger when
  285
+  :setting:`DEBUG` is `True` are sent to the console (unless you redefine the
  286
+  logger in your :setting:`LOGGING` setting).
  287
+
  288
+* When using :class:`~django.template.RequestContext`, it is now possible to
  289
+  look up permissions by using ``{% if 'someapp.someperm' in perms %}``
  290
+  in templates.
  291
+
  292
+* It's not required any more to have ``404.html`` and ``500.html`` templates in
  293
+  the root templates directory. Django will output some basic error messages for
  294
+  both situations when those templates are not found. Of course, it's still
  295
+  recommended as good practice to provide those templates in order to present
  296
+  pretty error pages to the user.
  297
+
  298
+* :mod:`django.contrib.auth` provides a new signal that is emitted
  299
+  whenever a user fails to login successfully. See
  300
+  :data:`~django.contrib.auth.signals.user_login_failed`
  301
+
  302
+* The loaddata management command now supports an `ignorenonexistent` option to
  303
+  ignore data for fields that no longer exist.
  304
+
  305
+* :meth:`~django.test.SimpleTestCase.assertXMLEqual` and
  306
+  :meth:`~django.test.SimpleTestCase.assertXMLNotEqual` new assertions allow
  307
+  you to test equality for XML content at a semantic level, without caring for
  308
+  syntax differences (spaces, attribute order, etc.).
  309
+
  310
+* RemoteUserMiddleware now forces logout when the REMOTE_USER header
  311
+  disappears during the same browser session.
  312
+
  313
+* The :ref:`cache-based session backend <cached-sessions-backend>` can store
  314
+  session data in a non-default cache.
  315
+
  316
+* Multi-column indexes can now be created on models. Read the
  317
+  :attr:`~django.db.models.Options.index_together` documentation for more
  318
+  information.
  319
+
  320
+* During Django's logging configuration verbose Deprecation warnings are
  321
+  enabled and warnings are captured into the logging system. Logged warnings
  322
+  are routed through the ``console`` logging handler, which by default requires
  323
+  :setting:`DEBUG` to be True for output to be generated. The result is that
  324
+  DeprecationWarnings should be printed to the console in development
  325
+  environments the way they have been in Python versions < 2.7.
  326
+
  327
+* The API for :meth:`django.contrib.admin.ModelAdmin.message_user` method has
  328
+  been modified to accept additional arguments adding capabilities similar to
  329
+  :func:`django.contrib.messages.add_message`. This is useful for generating
  330
+  error messages from admin actions.
  331
+
  332
+* The admin's list filters can now be customized per-request thanks to the new
  333
+  :meth:`django.contrib.admin.ModelAdmin.get_list_filter` method.
  334
+
  335
+Backwards incompatible changes in 1.5
  336
+=====================================
  337
+
  338
+.. warning::
  339
+
  340
+    In addition to the changes outlined in this section, be sure to review the
  341
+    :doc:`deprecation plan </internals/deprecation>` for any features that
  342
+    have been removed. If you haven't updated your code within the
  343
+    deprecation timeline for a given feature, its removal may appear as a
  344
+    backwards incompatible change.
  345
+
  346
+Context in year archive class-based views
  347
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  348
+
  349
+For consistency with the other date-based generic views,
  350
+:class:`~django.views.generic.dates.YearArchiveView` now passes ``year`` in
  351
+the context as a :class:`datetime.date` rather than a string.  If you are
  352
+using ``{{ year }}`` in your templates, you must replace it with ``{{
  353
+year|date:"Y" }}``.
  354
+
  355
+``next_year`` and ``previous_year`` were also added in the context. They are
  356
+calculated according to ``allow_empty`` and ``allow_future``.
  357
+
  358
+Context in year and month archive class-based views
  359
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  360
+
  361
+:class:`~django.views.generic.dates.YearArchiveView` and
  362
+:class:`~django.views.generic.dates.MonthArchiveView` were documented to
  363
+provide a ``date_list`` sorted in ascending order in the context, like their
  364
+function-based predecessors, but it actually was in descending order. In 1.5,
  365
+the documented order was restored. You may want to add (or remove) the
  366
+``reversed`` keyword when you're iterating on ``date_list`` in a template::
  367
+
  368
+    {% for date in date_list reversed %}
  369
+
  370
+:class:`~django.views.generic.dates.ArchiveIndexView` still provides a
  371
+``date_list`` in descending order.
  372
+
  373
+Context in TemplateView
  374
+~~~~~~~~~~~~~~~~~~~~~~~
  375
+
  376
+For consistency with the design of the other generic views,
  377
+:class:`~django.views.generic.base.TemplateView` no longer passes a ``params``
  378
+dictionary into the context, instead passing the variables from the URLconf
  379
+directly into the context.
  380
+
  381
+Non-form data in HTTP requests
  382
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  383
+
  384
+:attr:`request.POST <django.http.HttpRequest.POST>` will no longer include data
  385
+posted via HTTP requests with non form-specific content-types in the header.
  386
+In prior versions, data posted with content-types other than
  387
+``multipart/form-data`` or ``application/x-www-form-urlencoded`` would still
  388
+end up represented in the :attr:`request.POST <django.http.HttpRequest.POST>`
  389
+attribute. Developers wishing to access the raw POST data for these cases,
  390
+should use the :attr:`request.body <django.http.HttpRequest.body>` attribute
  391
+instead.
  392
+
  393
+OPTIONS, PUT and DELETE requests in the test client
  394
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  395
+
  396
+Unlike GET and POST, these HTTP methods aren't implemented by web browsers.
  397
+Rather, they're used in APIs, which transfer data in various formats such as
  398
+JSON or XML. Since such requests may contain arbitrary data, Django doesn't
  399
+attempt to decode their body.
  400
+
  401
+However, the test client used to build a query string for OPTIONS and DELETE
  402
+requests like for GET, and a request body for PUT requests like for POST. This
  403
+encoding was arbitrary and inconsistent with Django's behavior when it
  404
+receives the requests, so it was removed in Django 1.5.
  405
+
  406
+If you were using the ``data`` parameter in an OPTIONS or a DELETE request,
  407
+you must convert it to a query string and append it to the ``path`` parameter.
  408
+
  409
+If you were using the ``data`` parameter in a PUT request without a
  410
+``content_type``, you must encode your data before passing it to the test
  411
+client and set the ``content_type`` argument.
  412
+
  413
+.. _simplejson-incompatibilities-beta-1:
  414
+
  415
+System version of :mod:`simplejson` no longer used
  416
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  417
+
  418
+:ref:`As explained below <simplejson-deprecation-beta-1>`, Django 1.5 deprecates
  419
+:mod:`django.utils.simplejson` in favor of Python 2.6's built-in :mod:`json`
  420
+module. In theory, this change is harmless. Unfortunately, because of
  421
+incompatibilities between versions of :mod:`simplejson`, it may trigger errors
  422
+in some circumstances.
  423
+
  424
+JSON-related features in Django 1.4 always used :mod:`django.utils.simplejson`.
  425
+This module was actually:
  426
+
  427
+- A system version of :mod:`simplejson`, if one was available (ie. ``import
  428
+  simplejson`` works), if it was more recent than Django's built-in copy or it
  429
+  had the C speedups, or
  430
+- The :mod:`json` module from the standard library, if it was available (ie.
  431
+  Python 2.6 or greater), or
  432
+- A built-in copy of version 2.0.7 of :mod:`simplejson`.
  433
+
  434
+In Django 1.5, those features use Python's :mod:`json` module, which is based
  435
+on version 2.0.9 of :mod:`simplejson`.
  436
+
  437
+There are no known incompatibilities between Django's copy of version 2.0.7 and
  438
+Python's copy of version 2.0.9. However, there are some incompatibilities
  439
+between other versions of :mod:`simplejson`:
  440
+
  441
+- While the :mod:`simplejson` API is documented as always returning unicode
  442
+  strings, the optional C implementation can return a byte string. This was
  443
+  fixed in Python 2.7.
  444
+- :class:`simplejson.JSONEncoder` gained a ``namedtuple_as_object`` keyword
  445
+  argument in version 2.2.
  446
+
  447
+More information on these incompatibilities is available in `ticket #18023`_.
  448
+
  449
+The net result is that, if you have installed :mod:`simplejson` and your code
  450
+uses Django's serialization internals directly -- for instance
  451
+:class:`django.core.serializers.json.DjangoJSONEncoder`, the switch from
  452
+:mod:`simplejson` to :mod:`json` could break your code. (In general, changes to
  453
+internals aren't documented; we're making an exception here.)
  454
+
  455
+At this point, the maintainers of Django believe that using :mod:`json` from
  456
+the standard library offers the strongest guarantee of backwards-compatibility.
  457
+They recommend to use it from now on.
  458
+
  459
+.. _ticket #18023: https://code.djangoproject.com/ticket/18023#comment:10
  460
+
  461
+String types of hasher method parameters
  462
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  463
+
  464
+If you have written a :ref:`custom password hasher <auth_password_storage>`,
  465
+your ``encode()``, ``verify()`` or ``safe_summary()`` methods should accept
  466
+Unicode parameters (``password``, ``salt`` or ``encoded``). If any of the
  467
+hashing methods need byte strings, you can use the
  468
+:func:`~django.utils.encoding.force_bytes` utility to encode the strings.
  469
+
  470
+Validation of previous_page_number and next_page_number
  471
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  472
+
  473
+When using :doc:`object pagination </topics/pagination>`,
  474
+the ``previous_page_number()`` and ``next_page_number()`` methods of the
  475
+:class:`~django.core.paginator.Page` object did not check if the returned
  476
+number was inside the existing page range.
  477
+It does check it now and raises an :exc:`InvalidPage` exception when the number
  478
+is either too low or too high.
  479
+
  480
+Behavior of autocommit database option on PostgreSQL changed
  481
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  482
+
  483
+PostgreSQL's autocommit option didn't work as advertised previously. It did
  484
+work for single transaction block, but after the first block was left the
  485
+autocommit behavior was never restored. This bug is now fixed in 1.5. While
  486
+this is only a bug fix, it is worth checking your applications behavior if
  487
+you are using PostgreSQL together with the autocommit option.
  488
+
  489
+Session not saved on 500 responses
  490
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  491
+
  492
+Django's session middleware will skip saving the session data if the
  493
+response's status code is 500.
  494
+
  495
+Email checks on failed admin login
  496
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  497
+
  498
+Prior to Django 1.5, if you attempted to log into the admin interface and
  499
+mistakenly used your email address instead of your username, the admin
  500
+interface would provide a warning advising that your email address was
  501
+not your username. In Django 1.5, the introduction of
  502
+:ref:`custom User models <auth-custom-user>` has required the removal of this
  503
+warning. This doesn't change the login behavior of the admin site; it only
  504
+affects the warning message that is displayed under one particular mode of
  505
+login failure.
  506
+
  507
+Changes in tests execution
  508
+~~~~~~~~~~~~~~~~~~~~~~~~~~
  509
+
  510
+Some changes have been introduced in the execution of tests that might be
  511
+backward-incompatible for some testing setups:
  512
+
  513
+Database flushing in ``django.test.TransactionTestCase``
  514
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  515
+
  516
+Previously, the test database was truncated *before* each test run in a
  517
+:class:`~django.test.TransactionTestCase`.
  518
+
  519
+In order to be able to run unit tests in any order and to make sure they are
  520
+always isolated from each other, :class:`~django.test.TransactionTestCase` will
  521
+now reset the database *after* each test run instead.
  522
+
  523
+No more implicit DB sequences reset
  524
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  525
+
  526
+:class:`~django.test.TransactionTestCase` tests used to reset primary key
  527
+sequences automatically together with the database flushing actions described
  528
+above.
  529
+
  530
+This has been changed so no sequences are implicitly reset. This can cause
  531
+:class:`~django.test.TransactionTestCase` tests that depend on hard-coded
  532
+primary key values to break.
  533
+
  534
+The new :attr:`~django.test.TransactionTestCase.reset_sequences` attribute can
  535
+be used to force the old behavior for :class:`~django.test.TransactionTestCase`
  536
+that might need it.
  537
+
  538
+Ordering of tests
  539
+^^^^^^^^^^^^^^^^^
  540
+
  541
+In order to make sure all ``TestCase`` code starts with a clean database,
  542
+tests are now executed in the following order:
  543
+
  544
+* First, all unittests (including :class:`unittest.TestCase`,
  545
+  :class:`~django.test.SimpleTestCase`, :class:`~django.test.TestCase` and
  546
+  :class:`~django.test.TransactionTestCase`) are run with no particular ordering
  547
+  guaranteed nor enforced among them.
  548
+
  549
+* Then any other tests (e.g. doctests) that may alter the database without
  550
+  restoring it to its original state are run.
  551
+
  552
+This should not cause any problems unless you have existing doctests which
  553
+assume a :class:`~django.test.TransactionTestCase` executed earlier left some
  554
+database state behind or unit tests that rely on some form of state being
  555
+preserved after the execution of other tests. Such tests are already very
  556
+fragile, and must now be changed to be able to run independently.
  557
+
  558
+`cleaned_data` dictionary kept for invalid forms
  559
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  560
+
  561
+The :attr:`~django.forms.Form.cleaned_data` dictionary is now always present
  562
+after form validation. When the form doesn't validate, it contains only the
  563
+fields that passed validation. You should test the success of the validation
  564
+with the :meth:`~django.forms.Form.is_valid()` method and not with the
  565
+presence or absence of the :attr:`~django.forms.Form.cleaned_data` attribute
  566
+on the form.
  567
+
  568
+Behavior of :djadmin:`syncdb` with multiple databases
  569
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  570
+
  571
+:djadmin:`syncdb` now queries the database routers to determine if content
  572
+types (when :mod:`~django.contrib.contenttypes` is enabled) and permissions
  573
+(when :mod:`~django.contrib.auth` is enabled) should be created in the target
  574
+database. Previously, it created them in the default database, even when
  575
+another database was specified with the :djadminopt:`--database` option.
  576
+
  577
+If you use :djadmin:`syncdb` on multiple databases, you should ensure that
  578
+your routers allow synchronizing content types and permissions to only one of
  579
+them. See the docs on the :ref:`behavior of contrib apps with multiple
  580
+databases <contrib_app_multiple_databases>` for more information.
  581
+
  582
+Miscellaneous
  583
+~~~~~~~~~~~~~
  584
+
  585
+* :class:`django.forms.ModelMultipleChoiceField` now returns an empty
  586
+  ``QuerySet`` as the empty value instead of an empty list.
  587
+
  588
+* :func:`~django.utils.http.int_to_base36` properly raises a :exc:`TypeError`
  589
+  instead of :exc:`ValueError` for non-integer inputs.
  590
+
  591
+* The ``slugify`` template filter is now available as a standard python
  592
+  function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
  593
+  available at :func:`django.utils.html.remove_tags`.
  594
+
  595
+* Uploaded files are no longer created as executable by default. If you need
  596
+  them to be executable change :setting:`FILE_UPLOAD_PERMISSIONS` to your
  597
+  needs. The new default value is `0666` (octal) and the current umask value
  598
+  is first masked out.
  599
+
  600
+* The :ref:`F() expressions <query-expressions>` supported bitwise operators by
  601
+  ``&`` and ``|``. These operators are now available using ``.bitand()`` and
  602
+  ``.bitor()`` instead. The removal of ``&`` and ``|`` was done to be consistent with
  603
+  :ref:`Q() expressions <complex-lookups-with-q>` and ``QuerySet`` combining where
  604
+  the operators are used as boolean AND and OR operators.
  605
+
  606
+* In a ``filter()`` call, when :ref:`F() expressions <query-expressions>`
  607
+  contained lookups spanning multi-valued relations, they didn't always reuse
  608
+  the same relations as other lookups along the same chain. This was changed,
  609
+  and now F() expressions will always use the same relations as other lookups
  610
+  within the same ``filter()`` call.
  611
+
  612
+* The :ttag:`csrf_token` template tag is no longer enclosed in a div. If you need
  613
+  HTML validation against pre-HTML5 Strict DTDs, you should add a div around it
  614
+  in your pages.
  615
+
  616
+* The template tags library ``adminmedia``, which only contained the
  617
+  deprecated template tag ``{% admin_media_prefix %}``, was removed.
  618
+  Attempting to load it with ``{% load adminmedia %}`` will fail. If your
  619
+  templates still contain that line you must remove it.
  620
+
  621
+Features deprecated in 1.5
  622
+==========================
  623
+
  624
+.. _simplejson-deprecation-beta-1:
  625
+
  626
+:setting:`AUTH_PROFILE_MODULE`
  627
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  628
+
  629
+With the introduction of :ref:`custom User models <auth-custom-user>`, there is
  630
+no longer any need for a built-in mechanism to store user profile data.
  631
+
  632
+You can still define user profiles models that have a one-to-one relation with
  633
+the User model - in fact, for many applications needing to associate data with
  634
+a User account, this will be an appropriate design pattern to follow. However,
  635
+the :setting:`AUTH_PROFILE_MODULE` setting, and the
  636
+:meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
  637
+the user profile model, should not be used any longer.
  638
+
  639
+Streaming behavior of :class:`HttpResponse`
  640
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  641
+
  642
+Django 1.5 deprecates the ability to stream a response by passing an iterator
  643
+to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
  644
+:class:`~django.http.StreamingHttpResponse`. See
  645
+:ref:`explicit-streaming-responses-beta-1` above.
  646
+
  647
+In Django 1.7 and above, the iterator will be consumed immediately by
  648
+:class:`~django.http.HttpResponse`.
  649
+
  650
+``django.utils.simplejson``
  651
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
  652
+
  653
+Since Django 1.5 drops support for Python 2.5, we can now rely on the
  654
+:mod:`json` module being available in Python's standard library, so we've
  655
+removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
  656
+instead :mod:`django.utils.simplejson`.
  657
+
  658
+Unfortunately, this change might have unwanted side-effects, because of
  659
+incompatibilities between versions of :mod:`simplejson` -- see the
  660
+:ref:`backwards-incompatible changes <simplejson-incompatibilities-beta-1>` section.
  661
+If you rely on features added to :mod:`simplejson` after it became Python's
  662
+:mod:`json`, you should import :mod:`simplejson` explicitly.
  663
+
  664
+``django.utils.encoding.StrAndUnicode``
  665
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  666
+
  667
+The :class:`~django.utils.encoding.StrAndUnicode` mix-in has been deprecated.
  668
+Define a ``__str__`` method and apply the
  669
+:func:`~django.utils.encoding.python_2_unicode_compatible` decorator instead.
  670
+
  671
+``django.utils.itercompat.product``
  672
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  673
+
  674
+The :func:`~django.utils.itercompat.product` function has been deprecated. Use
  675
+the built-in :func:`itertools.product` instead.
  676
+
  677
+``django.utils.markup``
  678
+~~~~~~~~~~~~~~~~~~~~~~~
  679
+
  680
+The markup contrib module has been deprecated and will follow an accelerated
  681
+deprecation schedule. Direct use of python markup libraries or 3rd party tag
  682
+libraries is preferred to Django maintaining this functionality in the
  683
+framework.
  684
+
  685
+``cleanup`` management command
  686
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  687
+
  688
+The :djadmin:`cleanup` management command has been deprecated and replaced by
  689
+:djadmin:`clearsessions`.
  690
+
  691
+``daily_cleanup.py`` script
  692
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
  693
+
  694
+The undocumented ``daily_cleanup.py`` script has been deprecated. Use the
  695
+:djadmin:`clearsessions` management command instead.
  696
+
  697
+``depth`` keyword argument in ``select_related``
  698
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  699
+
  700
+The ``depth`` keyword argument in
  701
+:meth:`~django.db.models.query.QuerySet.select_related` has been deprecated.
  702
+You should use field names instead.
1  docs/releases/index.txt
@@ -92,6 +92,7 @@ notes.
92 92
 .. toctree::
93 93
    :maxdepth: 1
94 94
 
  95
+   1.5-beta-1
95 96
    1.5-alpha-1
96 97
    1.4-beta-1
97 98
    1.4-alpha-1

0 notes on commit 28120a9

Please sign in to comment.
Something went wrong with that request. Please try again.