Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Added structure in the 1.6 release notes.

The backwards-incompatible changes section wasn't structured in sections
like it is in release notes for previous versions.
  • Loading branch information...
commit 0555ef7c23cbbd991270d529cff48d96de801622 1 parent 9d4a5b0
Aymeric Augustin authored March 17, 2013

Showing 1 changed file with 120 additions and 62 deletions. Show diff stats Hide diff stats

  1. 182  docs/releases/1.6.txt
182  docs/releases/1.6.txt
@@ -165,69 +165,110 @@ Backwards incompatible changes in 1.6
165 165
     deprecation timeline for a given feature, its removal may appear as a
166 166
     backwards incompatible change.
167 167
 
168  
-* Database-level autocommit is enabled by default in Django 1.6. While this
169  
-  doesn't change the general spirit of Django's transaction management, there
170  
-  are a few known backwards-incompatibities, described in the :ref:`transaction
171  
-  management docs <transactions-upgrading-from-1.5>`. You should review your code
172  
-  to determine if you're affected.
  168
+New transaction management model
  169
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  170
+
  171
+Database-level autocommit is enabled by default in Django 1.6. While this
  172
+doesn't change the general spirit of Django's transaction management, there
  173
+are a few known backwards-incompatibities, described in the :ref:`transaction
  174
+management docs <transactions-upgrading-from-1.5>`. You should review your
  175
+code to determine if you're affected.
  176
+
  177
+In previous versions, database-level autocommit was only an option for
  178
+PostgreSQL, and it was disabled by default. This option is now :ref:`ignored
  179
+<postgresql-autocommit-mode>` and can be removed.
  180
+
  181
+Addition of ``QuerySet.datetimes()``
  182
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  183
+
  184
+When the :doc:`time zone support </topics/i18n/timezones>` added in Django 1.4
  185
+was active, :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>`
  186
+lookups returned unexpected results, because the aggregation was performed in
  187
+UTC. To fix this, Django 1.6 introduces a new API, :meth:`QuerySet.datetimes()
  188
+<django.db.models.query.QuerySet.datetimes>`. This requires a few changes in
  189
+your code.
173 190
 
174  
-* In previous versions, database-level autocommit was only an option for
175  
-  PostgreSQL, and it was disabled by default. This option is now
176  
-  :ref:`ignored <postgresql-autocommit-mode>`.
  191
+``QuerySet.dates()`` returns ``date`` objects
  192
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
177 193
 
178  
-* The ``django.db.models.query.EmptyQuerySet`` can't be instantiated any more -
179  
-  it is only usable as a marker class for checking if
180  
-  :meth:`~django.db.models.query.QuerySet.none` has been called:
181  
-  ``isinstance(qs.none(), EmptyQuerySet)``
  194
+:meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` now returns a
  195
+list of :class:`~datetime.date`. It used to return a list of
  196
+:class:`~datetime.datetime`.
182 197
 
183  
-* :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` raises an
184  
-  error if it's used on :class:`~django.db.models.DateTimeField` when time
185  
-  zone support is active. Use :meth:`QuerySet.datetimes()
186  
-  <django.db.models.query.QuerySet.datetimes>` instead.
  198
+:meth:`QuerySet.datetimes() <django.db.models.query.QuerySet.datetimes>`
  199
+returns a list of :class:`~datetime.datetime`.
187 200
 
188  
-* :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` returns a
189  
-  list of :class:`~datetime.date`. It used to return a list of
190  
-  :class:`~datetime.datetime`.
  201
+``QuerySet.dates()`` no longer usable on ``DateTimeField``
  202
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
191 203
 
192  
-* The :attr:`~django.contrib.admin.ModelAdmin.date_hierarchy` feature of the
193  
-  admin on a :class:`~django.db.models.DateTimeField` requires time zone
194  
-  definitions in the database when :setting:`USE_TZ` is ``True``.
195  
-  :ref:`Learn more <database-time-zone-definitions>`.
  204
+:meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` raises an
  205
+error if it's used on :class:`~django.db.models.DateTimeField` when time
  206
+zone support is active. Use :meth:`QuerySet.datetimes()
  207
+<django.db.models.query.QuerySet.datetimes>` instead.
196 208
 
197  
-* Accessing ``date_list`` in the context of a date-based generic view requires
198  
-  time zone definitions in the database when the view is based on a
199  
-  :class:`~django.db.models.DateTimeField` and :setting:`USE_TZ` is ``True``.
200  
-  :ref:`Learn more <database-time-zone-definitions>`.
  209
+``date_hierarchy`` requires time zone definitions
  210
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
201 211
 
202  
-* Model fields named ``hour``, ``minute`` or ``second`` may clash with the new
203  
-  lookups. Append an explicit :lookup:`exact` lookup if this is an issue.
  212
+The :attr:`~django.contrib.admin.ModelAdmin.date_hierarchy` feature of the
  213
+admin now relies on :meth:`QuerySet.datetimes()
  214
+<django.db.models.query.QuerySet.datetimes>` when it's used on a
  215
+:class:`~django.db.models.DateTimeField`.
204 216
 
205  
-* When Django establishes a connection to the database, it sets up appropriate
206  
-  parameters, depending on the backend being used. Since `persistent database
207  
-  connections <persistent-database-connections>`_ are enabled by default in
208  
-  Django 1.6, this setup isn't repeated at every request any more. If you
209  
-  modifiy parameters such as the connection's isolation level or time zone,
210  
-  you should either restore Django's defaults at the end of each request, or
211  
-  force an appropriate value at the beginning of each request.
  217
+This requires time zone definitions in the database when :setting:`USE_TZ` is
  218
+``True``. :ref:`Learn more <database-time-zone-definitions>`.
212 219
 
213  
-* If your CSS/Javascript code used to access HTML input widgets by type, you
214  
-  should review it as ``type='text'`` widgets might be now output as
215  
-  ``type='email'``, ``type='url'`` or ``type='number'`` depending on their
216  
-  corresponding field type.
  220
+``date_list`` in generic views requires time zone definitions
  221
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
217 222
 
218  
-* Extraction of translatable literals from templates with the
219  
-  :djadmin:`makemessages` command now correctly detects i18n constructs when
220  
-  they are located after a ``{#`` / ``#}``-type comment on the same line. E.g.:
  223
+For the same reason, accessing ``date_list`` in the context of a date-based
  224
+generic view requires time zone definitions in the database when the view is
  225
+based on a :class:`~django.db.models.DateTimeField` and :setting:`USE_TZ` is
  226
+``True``. :ref:`Learn more <database-time-zone-definitions>`.
221 227
 
222  
-  .. code-block:: html+django
  228
+New lookups may clash with model fields
  229
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  230
+
  231
+Django 1.6 introduces ``hour``, ``minute``, and ``second`` lookups on
  232
+:class:`~django.db.models.DateTimeField`. If you had model fields called
  233
+``hour``, ``minute``, or ``second``, the new lookups will clash with you field
  234
+names. Append an explicit :lookup:`exact` lookup if this is an issue.
  235
+
  236
+Persistent database connections
  237
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  238
+
  239
+Connection setup not repeated for each request
  240
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  241
+
  242
+When Django establishes a connection to the database, it sets up appropriate
  243
+parameters, depending on the backend being used. Since `persistent database
  244
+connections <persistent-database-connections>`_ are enabled by default in
  245
+Django 1.6, this setup isn't repeated at every request any more. If you
  246
+modifiy parameters such as the connection's isolation level or time zone, you
  247
+should either restore Django's defaults at the end of each request, force an
  248
+appropriate value at the beginning of each request, or disable persistent
  249
+connections.
  250
+
  251
+Translations and comments in templates
  252
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  253
+
  254
+Extraction of translations after comments
  255
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  256
+
  257
+Extraction of translatable literals from templates with the
  258
+:djadmin:`makemessages` command now correctly detects i18n constructs when
  259
+they are located after a ``{#`` / ``#}``-type comment on the same line. E.g.:
  260
+
  261
+.. code-block:: html+django
223 262
 
224 263
     {# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %}
225 264
 
226  
-* (Related to the above item.) Validation of the placement of
227  
-  :ref:`translator-comments-in-templates` specified using ``{#`` / ``#}`` is now
228  
-  stricter. All translator comments not located at the end of their respective
229  
-  lines in a template are ignored and a warning is generated by
230  
-  :djadmin:`makemessages` when it finds them. E.g.:
  265
+Location of translator comments
  266
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  267
+
  268
+Validation of the placement of :ref:`translator-comments-in-templates`
  269
+specified using ``{#`` / ``#}`` is now stricter. All translator comments not
  270
+located at the end of their respective lines in a template are ignored and a
  271
+warning is generated by :djadmin:`makemessages` when it finds them. E.g.:
231 272
 
232 273
   .. code-block:: html+django
233 274
 
@@ -235,28 +276,45 @@ Backwards incompatible changes in 1.6
235 276
     {{ title }}{# Translators: Extracted and associated with 'Welcome' below #}
236 277
     <h1>{% trans "Welcome" %}</h1>
237 278
 
238  
-* The :doc:`comments </ref/contrib/comments/index>` app now uses a ``GenericIPAddressField``
239  
-  for storing commenters' IP addresses, to support comments submitted from IPv6 addresses.
240  
-  Until now, it stored them in an ``IPAddressField``, which is only meant to support IPv4.
241  
-  When saving a comment made from an IPv6 address, the address would be silently truncated
242  
-  on MySQL databases, and raise an exception on Oracle.
243  
-  You will need to change the column type in your database to benefit from this change.
  279
+Storage of IP addresses in the comments app
  280
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
244 281
 
245  
-  For MySQL, execute this query on your project's database:
  282
+The :doc:`comments </ref/contrib/comments/index>` app now uses a
  283
+``GenericIPAddressField`` for storing commenters' IP addresses, to support
  284
+comments submitted from IPv6 addresses. Until now, it stored them in an
  285
+``IPAddressField``, which is only meant to support IPv4. When saving a comment
  286
+made from an IPv6 address, the address would be silently truncated on MySQL
  287
+databases, and raise an exception on Oracle. You will need to change the
  288
+column type in your database to benefit from this change.
246 289
 
247  
-  .. code-block:: sql
  290
+For MySQL, execute this query on your project's database:
  291
+
  292
+.. code-block:: sql
248 293
 
249 294
     ALTER TABLE django_comments MODIFY ip_address VARCHAR(39);
250 295
 
251  
-  For Oracle, execute this query:
  296
+For Oracle, execute this query:
252 297
 
253  
-  .. code-block:: sql
  298
+.. code-block:: sql
254 299
 
255 300
     ALTER TABLE DJANGO_COMMENTS MODIFY (ip_address VARCHAR2(39));
256 301
 
257  
-  If you do not apply this change, the behaviour is unchanged: on MySQL, IPv6 addresses
258  
-  are silently truncated; on Oracle, an exception is generated. No database
259  
-  change is needed for SQLite or PostgreSQL databases.
  302
+If you do not apply this change, the behaviour is unchanged: on MySQL, IPv6
  303
+addresses are silently truncated; on Oracle, an exception is generated. No
  304
+database change is needed for SQLite or PostgreSQL databases.
  305
+
  306
+Miscellaneous
  307
+~~~~~~~~~~~~~
  308
+
  309
+* The ``django.db.models.query.EmptyQuerySet`` can't be instantiated any more -
  310
+  it is only usable as a marker class for checking if
  311
+  :meth:`~django.db.models.query.QuerySet.none` has been called:
  312
+  ``isinstance(qs.none(), EmptyQuerySet)``
  313
+
  314
+* If your CSS/Javascript code used to access HTML input widgets by type, you
  315
+  should review it as ``type='text'`` widgets might be now output as
  316
+  ``type='email'``, ``type='url'`` or ``type='number'`` depending on their
  317
+  corresponding field type.
260 318
 
261 319
 Features deprecated in 1.6
262 320
 ==========================

0 notes on commit 0555ef7

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