Used 🎫 role in all tickets links.
This commit is contained in:
parent
52936eface
commit
abc51d44af
|
@ -449,8 +449,8 @@ Backwards incompatible changes in 1.11
|
|||
dependency for GeoDjango. In older versions, it's only required for SQLite.
|
||||
|
||||
* ``contrib.gis.maps`` is removed as it interfaces with a retired version of
|
||||
the Google Maps API and seems to be unmaintained. If you're using it, `let
|
||||
us know <https://code.djangoproject.com/ticket/14284>`_.
|
||||
the Google Maps API and seems to be unmaintained. If you're using it,
|
||||
:ticket:`let us know <14284>`.
|
||||
|
||||
* The ``GEOSGeometry`` equality operator now also compares SRID.
|
||||
|
||||
|
|
|
@ -3,8 +3,6 @@ Django 1.2.1 release notes
|
|||
==========================
|
||||
|
||||
Django 1.2.1 was released almost immediately after 1.2.0 to correct two small
|
||||
bugs: one was in the documentation packaging script, the other was a bug_ that
|
||||
affected datetime form field widgets when localization was enabled.
|
||||
|
||||
.. _bug: https://code.djangoproject.com/ticket/13560
|
||||
|
||||
bugs: one was in the documentation packaging script, the other was a
|
||||
:ticket:`bug <13560>` that affected datetime form field widgets when
|
||||
localization was enabled.
|
||||
|
|
|
@ -66,12 +66,10 @@ configuration.
|
|||
|
||||
Most users -- even users with multiple-database configurations -- need
|
||||
not be concerned about the data loss bug, or the manual configuration of
|
||||
:setting:`TEST_DEPENDENCIES`. See the `original problem report`_
|
||||
:setting:`TEST_DEPENDENCIES`. See the :ticket:`original problem report <14415>`
|
||||
documentation on :ref:`controlling the creation order of test
|
||||
databases <topics-testing-creation-dependencies>` for details.
|
||||
|
||||
.. _original problem report: https://code.djangoproject.com/ticket/14415
|
||||
|
||||
GeoDjango
|
||||
=========
|
||||
|
||||
|
|
|
@ -10,9 +10,9 @@ compatible with Django 1.5, but includes a handful of fixes.
|
|||
The biggest fix is for a memory leak introduced in Django 1.5. Under certain
|
||||
circumstances, repeated iteration over querysets could leak memory - sometimes
|
||||
quite a bit of it. If you'd like more information, the details are in
|
||||
`our ticket tracker`__ (and in `a related issue`__ in Python itself).
|
||||
:ticket:`our ticket tracker <19895>` (and in `a related issue`__ in Python
|
||||
itself).
|
||||
|
||||
__ https://code.djangoproject.com/ticket/19895
|
||||
__ https://bugs.python.org/issue17468
|
||||
|
||||
If you've noticed memory problems under Django 1.5, upgrading to 1.5.1 should
|
||||
|
|
|
@ -505,7 +505,8 @@ between other versions of ``simplejson``:
|
|||
- ``simplejson.JSONEncoder`` gained a ``namedtuple_as_object`` keyword
|
||||
argument in version 2.2.
|
||||
|
||||
More information on these incompatibilities is available in `ticket #18023`_.
|
||||
More information on these incompatibilities is available in
|
||||
:ticket:`ticket #18023 <18023#comment:10>`.
|
||||
|
||||
The net result is that, if you have installed ``simplejson`` and your code
|
||||
uses Django's serialization internals directly -- for instance
|
||||
|
@ -517,8 +518,6 @@ At this point, the maintainers of Django believe that using :mod:`json` from
|
|||
the standard library offers the strongest guarantee of backwards-compatibility.
|
||||
They recommend to use it from now on.
|
||||
|
||||
.. _ticket #18023: https://code.djangoproject.com/ticket/18023#comment:10
|
||||
|
||||
String types of hasher method parameters
|
||||
----------------------------------------
|
||||
|
||||
|
|
|
@ -199,9 +199,8 @@ modified using any other ``QuerySet`` operation, including ``filter()``,
|
|||
Combining multiple aggregations
|
||||
-------------------------------
|
||||
|
||||
Combining multiple aggregations with ``annotate()`` will `yield the wrong
|
||||
results <https://code.djangoproject.com/ticket/10060>`_ because joins are used
|
||||
instead of subqueries:
|
||||
Combining multiple aggregations with ``annotate()`` will :ticket:`yield the
|
||||
wrong results <10060>` because joins are used instead of subqueries:
|
||||
|
||||
>>> book = Book.objects.first()
|
||||
>>> book.authors.count()
|
||||
|
|
|
@ -963,9 +963,8 @@ extra forms displayed.
|
|||
|
||||
Also, ``extra=0`` doesn't prevent creation of new model instances as you can
|
||||
:ref:`add additional forms with JavaScript <understanding-the-managementform>`
|
||||
or send additional POST data. Formsets `don't yet provide functionality
|
||||
<https://code.djangoproject.com/ticket/26142>`_ for an "edit only" view that
|
||||
prevents creation of new instances.
|
||||
or send additional POST data. Formsets :ticket:`don't yet provide functionality
|
||||
<26142>` for an "edit only" view that prevents creation of new instances.
|
||||
|
||||
If the value of ``max_num`` is greater than the number of existing related
|
||||
objects, up to ``extra`` additional blank forms will be added to the formset,
|
||||
|
|
|
@ -275,9 +275,7 @@ setting.
|
|||
Caches are not cleared after each test, and running "manage.py test fooapp" can
|
||||
insert data from the tests into the cache of a live system if you run your
|
||||
tests in production because, unlike databases, a separate "test cache" is not
|
||||
used. This behavior `may change`_ in the future.
|
||||
|
||||
.. _may change: https://code.djangoproject.com/ticket/11505
|
||||
used. This behavior :ticket:`may change <11505>` in the future.
|
||||
|
||||
Understanding the test output
|
||||
-----------------------------
|
||||
|
|
Loading…
Reference in New Issue