mirror of
https://github.com/django/django.git
synced 2025-10-23 21:59:11 +00:00
Removed versionadded/changed annotations for 5.0.
This also removes remaining versionadded/changed annotations for older versions.
This commit is contained in:
@@ -60,8 +60,6 @@ constraint.
|
||||
``violation_error_code``
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 5.0
|
||||
|
||||
.. attribute:: BaseConstraint.violation_error_code
|
||||
|
||||
The error code used when ``ValidationError`` is raised during
|
||||
@@ -263,8 +261,6 @@ creates a unique index on ``username`` using ``varchar_pattern_ops``.
|
||||
``nulls_distinct``
|
||||
------------------
|
||||
|
||||
.. versionadded:: 5.0
|
||||
|
||||
.. attribute:: UniqueConstraint.nulls_distinct
|
||||
|
||||
Whether rows containing ``NULL`` values covered by the unique constraint should
|
||||
@@ -284,8 +280,6 @@ PostgreSQL 15+.
|
||||
``violation_error_code``
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 5.0
|
||||
|
||||
.. attribute:: UniqueConstraint.violation_error_code
|
||||
|
||||
The error code used when ``ValidationError`` is raised during
|
||||
|
||||
@@ -569,11 +569,6 @@ Usage example:
|
||||
On Oracle, the SQL ``LOCALTIMESTAMP`` is used to avoid issues with casting
|
||||
``CURRENT_TIMESTAMP`` to ``DateTimeField``.
|
||||
|
||||
.. versionchanged:: 5.0
|
||||
|
||||
In older versions, the SQL ``CURRENT_TIMESTAMP`` was used on Oracle instead
|
||||
of ``LOCALTIMESTAMP``.
|
||||
|
||||
``Trunc``
|
||||
---------
|
||||
|
||||
|
||||
@@ -1053,8 +1053,6 @@ calling the appropriate methods on the wrapped expression.
|
||||
|
||||
.. attribute:: allowed_default
|
||||
|
||||
.. versionadded:: 5.0
|
||||
|
||||
Tells Django that this expression can be used in
|
||||
:attr:`Field.db_default`. Defaults to ``False``.
|
||||
|
||||
|
||||
@@ -138,10 +138,6 @@ the choices are:
|
||||
provide a well-known inventory of values, such as currencies, countries,
|
||||
languages, time zones, etc.
|
||||
|
||||
.. versionchanged:: 5.0
|
||||
|
||||
Support for mappings and callables was added.
|
||||
|
||||
Generally, it's best to define choices inside a model class, and to
|
||||
define a suitably-named constant for each value::
|
||||
|
||||
@@ -372,10 +368,6 @@ There are some additional caveats to be aware of:
|
||||
|
||||
__empty__ = _("(Unknown)")
|
||||
|
||||
.. versionchanged:: 5.0
|
||||
|
||||
Support for using enumeration types directly in the ``choices`` was added.
|
||||
|
||||
``db_column``
|
||||
-------------
|
||||
|
||||
@@ -405,8 +397,6 @@ looking at your Django code. For example::
|
||||
``db_default``
|
||||
--------------
|
||||
|
||||
.. versionadded:: 5.0
|
||||
|
||||
.. attribute:: Field.db_default
|
||||
|
||||
The database-computed default value for this field. This can be a literal value
|
||||
@@ -1235,8 +1225,6 @@ when :attr:`~django.forms.Field.localize` is ``False`` or
|
||||
``GeneratedField``
|
||||
------------------
|
||||
|
||||
.. versionadded:: 5.0
|
||||
|
||||
.. class:: GeneratedField(expression, output_field, db_persist=None, **kwargs)
|
||||
|
||||
A field that is always computed based on other fields in the model. This field
|
||||
|
||||
@@ -580,10 +580,6 @@ 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``.
|
||||
|
||||
.. versionchanged:: 5.0
|
||||
|
||||
The ``Field.db_default`` parameter was added.
|
||||
|
||||
.. _ref-models-force-insert:
|
||||
|
||||
Forcing an INSERT or UPDATE
|
||||
@@ -616,11 +612,6 @@ only.
|
||||
|
||||
Using ``update_fields`` will force an update similarly to ``force_update``.
|
||||
|
||||
.. versionchanged:: 5.0
|
||||
|
||||
Support for passing a tuple of parent classes to ``force_insert`` was
|
||||
added.
|
||||
|
||||
.. _ref-models-field-updates-using-f-expressions:
|
||||
|
||||
Updating attributes based on existing fields
|
||||
|
||||
@@ -1160,12 +1160,6 @@ supports prefetching of
|
||||
queryset for each ``ContentType`` must be provided in the ``querysets``
|
||||
parameter of :class:`~django.contrib.contenttypes.prefetch.GenericPrefetch`.
|
||||
|
||||
.. versionchanged:: 5.0
|
||||
|
||||
Support for prefetching
|
||||
:class:`~django.contrib.contenttypes.fields.GenericForeignKey` with
|
||||
non-homogeneous set of results was added.
|
||||
|
||||
For example, suppose you have these models::
|
||||
|
||||
from django.db import models
|
||||
@@ -2114,13 +2108,6 @@ SQL equivalent:
|
||||
2
|
||||
)
|
||||
|
||||
.. versionchanged:: 5.0
|
||||
|
||||
In older versions, on databases without native support for the SQL
|
||||
``XOR`` operator, ``XOR`` returned rows that were matched by exactly
|
||||
one operand. The previous behavior was not consistent with MySQL,
|
||||
MariaDB, and Python behavior.
|
||||
|
||||
Methods that do not return ``QuerySet``\s
|
||||
-----------------------------------------
|
||||
|
||||
@@ -2402,10 +2389,6 @@ Like :meth:`get_or_create` and :meth:`create`, if you're using manually
|
||||
specified primary keys and an object needs to be created but the key already
|
||||
exists in the database, an :exc:`~django.db.IntegrityError` is raised.
|
||||
|
||||
.. versionchanged:: 5.0
|
||||
|
||||
The ``create_defaults`` argument was added.
|
||||
|
||||
``bulk_create()``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -2470,11 +2453,6 @@ be in conflict must be provided.
|
||||
Enabling the ``ignore_conflicts`` parameter disables setting the primary key on
|
||||
each model instance (if the database normally supports it).
|
||||
|
||||
.. versionchanged:: 5.0
|
||||
|
||||
In older versions, enabling the ``update_conflicts`` parameter prevented
|
||||
setting the primary key on each model instance.
|
||||
|
||||
.. warning::
|
||||
|
||||
On MySQL and MariaDB, setting the ``ignore_conflicts`` parameter to
|
||||
@@ -2629,11 +2607,6 @@ evaluated will force it to evaluate again, repeating the query.
|
||||
long as ``chunk_size`` is given. Larger values will necessitate fewer queries
|
||||
to accomplish the prefetching at the cost of greater memory usage.
|
||||
|
||||
.. versionchanged:: 5.0
|
||||
|
||||
Support for ``aiterator()`` with previous calls to ``prefetch_related()``
|
||||
was added.
|
||||
|
||||
On some databases (e.g. Oracle, `SQLite
|
||||
<https://www.sqlite.org/limits.html#max_variable_number>`_), the maximum number
|
||||
of terms in an SQL ``IN`` clause might be limited. Hence values below this
|
||||
@@ -4162,10 +4135,6 @@ When using multiple databases with ``prefetch_related_objects``, the prefetch
|
||||
query will use the database associated with the model instance. This can be
|
||||
overridden by using a custom queryset in a related lookup.
|
||||
|
||||
.. versionchanged:: 5.0
|
||||
|
||||
``aprefetch_related_objects()`` function was added.
|
||||
|
||||
``FilteredRelation()`` objects
|
||||
------------------------------
|
||||
|
||||
|
||||
Reference in New Issue
Block a user