mirror of
https://github.com/django/django.git
synced 2025-08-03 18:38:50 +00:00
Removed versionadded/changed annotations for 1.6.
This commit is contained in:
parent
ec08d62a20
commit
51c8045145
54 changed files with 70 additions and 550 deletions
|
@ -384,8 +384,6 @@ guaranteed to fit numbers from ``-9223372036854775808`` to
|
|||
|
||||
.. class:: BinaryField([**options])
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
A field to store raw binary data. It only supports ``bytes`` assignment. Be
|
||||
aware that this field has limited functionality. For example, it is not possible
|
||||
to filter a queryset on a ``BinaryField`` value.
|
||||
|
@ -409,10 +407,8 @@ The default form widget for this field is a
|
|||
If you need to accept :attr:`~Field.null` values then use
|
||||
:class:`NullBooleanField` instead.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The default value of ``BooleanField`` was changed from ``False`` to
|
||||
``None`` when :attr:`Field.default` isn't defined.
|
||||
The default value of ``BooleanField`` is ``None`` when :attr:`Field.default`
|
||||
isn't defined.
|
||||
|
||||
``CharField``
|
||||
-------------
|
||||
|
@ -1142,8 +1138,6 @@ define the details of how the relation works.
|
|||
|
||||
.. attribute:: ForeignKey.related_query_name
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The name to use for the reverse filter name from the target model.
|
||||
Defaults to the value of :attr:`related_name` if it is set, otherwise it
|
||||
defaults to the name of the model::
|
||||
|
@ -1163,8 +1157,6 @@ define the details of how the relation works.
|
|||
|
||||
.. attribute:: ForeignKey.db_constraint
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Controls whether or not a constraint should be created in the database for
|
||||
this foreign key. The default is ``True``, and that's almost certainly what
|
||||
you want; setting this to ``False`` can be very bad for data integrity.
|
||||
|
@ -1292,8 +1284,6 @@ that control how the relationship functions.
|
|||
|
||||
.. attribute:: ManyToManyField.related_query_name
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Same as :attr:`ForeignKey.related_query_name`.
|
||||
|
||||
.. attribute:: ManyToManyField.limit_choices_to
|
||||
|
@ -1396,8 +1386,6 @@ that control how the relationship functions.
|
|||
|
||||
.. attribute:: ManyToManyField.db_constraint
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Controls whether or not constraints should be created in the database for
|
||||
the foreign keys in the intermediary table. The default is ``True``, and
|
||||
that's almost certainly what you want; setting this to ``False`` can be
|
||||
|
|
|
@ -86,14 +86,8 @@ validation errors yourself, or if you have excluded fields from the
|
|||
|
||||
.. method:: Model.full_clean(exclude=None, validate_unique=True)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``validate_unique`` parameter was added to allow skipping
|
||||
:meth:`Model.validate_unique()`. Previously, :meth:`Model.validate_unique()`
|
||||
was always called by ``full_clean``.
|
||||
|
||||
This method calls :meth:`Model.clean_fields()`, :meth:`Model.clean()`, and
|
||||
:meth:`Model.validate_unique()` (if ``validate_unique`` is ``True``, in that
|
||||
:meth:`Model.validate_unique()` (if ``validate_unique`` is ``True``), in that
|
||||
order and raises a :exc:`~django.core.exceptions.ValidationError` that has a
|
||||
``message_dict`` attribute containing errors from all three stages.
|
||||
|
||||
|
@ -310,17 +304,15 @@ value explicitly when saving new objects, if you cannot guarantee the
|
|||
primary-key value is unused. For more on this nuance, see `Explicitly specifying
|
||||
auto-primary-key values`_ above and `Forcing an INSERT or UPDATE`_ below.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previously Django did a ``SELECT`` when the primary key attribute was set.
|
||||
If the ``SELECT`` found a row, then Django did an ``UPDATE``, otherwise it
|
||||
did an ``INSERT``. The old algorithm results in one more query in the
|
||||
``UPDATE`` case. There are some rare cases where the database doesn't
|
||||
report that a row was updated even if the database contains a row for the
|
||||
object's primary key value. An example is the PostgreSQL ``ON UPDATE``
|
||||
trigger which returns ``NULL``. In such cases it is possible to revert to the
|
||||
old algorithm by setting the :attr:`~django.db.models.Options.select_on_save`
|
||||
option to ``True``.
|
||||
In Django 1.5 and earlier, Django did a ``SELECT`` when the primary key
|
||||
attribute was set. If the ``SELECT`` found a row, then Django did an ``UPDATE``,
|
||||
otherwise it did an ``INSERT``. The old algorithm results in one more query in
|
||||
the ``UPDATE`` case. There are some rare cases where the database doesn't
|
||||
report that a row was updated even if the database contains a row for the
|
||||
object's primary key value. An example is the PostgreSQL ``ON UPDATE`` trigger
|
||||
which returns ``NULL``. In such cases it is possible to revert to the old
|
||||
algorithm by setting the :attr:`~django.db.models.Options.select_on_save`
|
||||
option to ``True``.
|
||||
|
||||
.. _ref-models-force-insert:
|
||||
|
||||
|
|
|
@ -279,8 +279,6 @@ Django quotes column and table names behind the scenes.
|
|||
|
||||
.. attribute:: Options.select_on_save
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Determines if Django will use the pre-1.6
|
||||
:meth:`django.db.models.Model.save()` algorithm. The old algorithm
|
||||
uses ``SELECT`` to determine if there is an existing row to be updated.
|
||||
|
@ -344,7 +342,7 @@ Django quotes column and table names behind the scenes.
|
|||
|
||||
For convenience, ``index_together`` can be a single list when dealing with a single
|
||||
set of fields::
|
||||
|
||||
|
||||
index_together = ["pub_date", "deadline"]
|
||||
|
||||
``verbose_name``
|
||||
|
|
|
@ -585,16 +585,7 @@ Returns a ``DateQuerySet`` — a ``QuerySet`` that evaluates to a list of
|
|||
:class:`datetime.date` objects representing all available dates of a
|
||||
particular kind within the contents of the ``QuerySet``.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
``dates`` used to return a list of :class:`datetime.datetime` objects.
|
||||
|
||||
``field`` should be the name of a ``DateField`` of your model.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
``dates`` used to accept operating on a ``DateTimeField``.
|
||||
|
||||
``kind`` should be either ``"year"``, ``"month"`` or ``"day"``. Each
|
||||
``datetime.date`` object in the result list is "truncated" to the given
|
||||
``type``.
|
||||
|
@ -624,8 +615,6 @@ Examples::
|
|||
datetimes
|
||||
~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
.. method:: datetimes(field, kind, order='ASC', tzinfo=None)
|
||||
|
||||
Returns a ``DateTimeQuerySet`` — a ``QuerySet`` that evaluates to a list of
|
||||
|
@ -769,8 +758,6 @@ follow all non-null foreign keys it can find - nullable foreign keys must be
|
|||
specified. This is not recommended in most cases as it is likely to make the
|
||||
underlying query more complex, and return more data, than is actually needed.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
If you need to clear the list of related fields added by past calls of
|
||||
``select_related`` on a ``QuerySet``, you can pass ``None`` as a parameter::
|
||||
|
||||
|
@ -1474,10 +1461,6 @@ get_or_create
|
|||
A convenience method for looking up an object with the given ``kwargs`` (may be
|
||||
empty if your model has defaults for all fields), creating one if necessary.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Older versions of Django required ``kwargs``.
|
||||
|
||||
Returns a tuple of ``(object, created)``, where ``object`` is the retrieved or
|
||||
created object and ``created`` is a boolean specifying whether a new object was
|
||||
created.
|
||||
|
@ -1762,16 +1745,13 @@ earliest
|
|||
|
||||
.. method:: earliest(field_name=None)
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Works otherwise like :meth:`~django.db.models.query.QuerySet.latest` except
|
||||
the direction is changed.
|
||||
|
||||
first
|
||||
~~~~~
|
||||
.. method:: first()
|
||||
|
||||
.. versionadded:: 1.6
|
||||
.. method:: first()
|
||||
|
||||
Returns the first object matched by the queryset, or ``None`` if there
|
||||
is no matching object. If the ``QuerySet`` has no ordering defined, then the
|
||||
|
@ -1793,8 +1773,6 @@ last
|
|||
~~~~
|
||||
.. method:: last()
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Works like :meth:`first()`, but returns the last object in the queryset.
|
||||
|
||||
aggregate
|
||||
|
@ -2435,8 +2413,6 @@ in the database <database-time-zone-definitions>`.
|
|||
hour
|
||||
~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
For datetime fields, an exact hour match. Takes an integer between 0 and 23.
|
||||
|
||||
Example::
|
||||
|
@ -2457,8 +2433,6 @@ zone before filtering.
|
|||
minute
|
||||
~~~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
For datetime fields, an exact minute match. Takes an integer between 0 and 59.
|
||||
|
||||
Example::
|
||||
|
@ -2479,8 +2453,6 @@ zone before filtering.
|
|||
second
|
||||
~~~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
For datetime fields, an exact second match. Takes an integer between 0 and 59.
|
||||
|
||||
Example::
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue