mirror of https://github.com/django/django.git
Removed versionadded/changed annotations for 4.1.
This commit is contained in:
Mariusz Felisiak
parent
ea92a4dc28
commit
490cccbe7e
|
|
@ -319,8 +319,6 @@ reconstructing the field::
|
|||
Field attributes not affecting database column definition
|
||||
---------------------------------------------------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
You can override ``Field.non_db_attrs`` to customize attributes of a field that
|
||||
don't affect a column definition. It's used during model migrations to detect
|
||||
no-op ``AlterField`` operations.
|
||||
|
|
|
|||
|
|
@ -70,11 +70,6 @@ If rotating secret keys, you may use :setting:`SECRET_KEY_FALLBACKS`::
|
|||
Ensure that old secret keys are removed from ``SECRET_KEY_FALLBACKS`` in a
|
||||
timely manner.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``SECRET_KEY_FALLBACKS`` setting was added to support rotating secret
|
||||
keys.
|
||||
|
||||
:setting:`DEBUG`
|
||||
----------------
|
||||
|
||||
|
|
|
|||
|
|
@ -83,11 +83,6 @@ MRO is an acronym for Method Resolution Order.
|
|||
asynchronous (``async def``) and synchronous (``def``) handlers are
|
||||
defined on a single view-class.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Compatibility with asynchronous (``async def``) method handlers was
|
||||
added.
|
||||
|
||||
.. method:: setup(request, *args, **kwargs)
|
||||
|
||||
Performs key view initialization prior to :meth:`dispatch`.
|
||||
|
|
@ -126,11 +121,6 @@ MRO is an acronym for Method Resolution Order.
|
|||
(``async def``) then the response will be wrapped in a coroutine
|
||||
function for use with ``await``.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Compatibility with classes defining asynchronous (``async def``)
|
||||
method handlers was added.
|
||||
|
||||
``TemplateView``
|
||||
================
|
||||
|
||||
|
|
|
|||
|
|
@ -1186,22 +1186,6 @@ subclass::
|
|||
:meth:`ModelAdmin.get_search_results` to provide additional or alternate
|
||||
search behavior.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Searches using multiple search terms are now applied in a single call
|
||||
to ``filter()``, rather than in sequential ``filter()`` calls.
|
||||
|
||||
For multi-valued relationships, this means that rows from the related
|
||||
model must match all terms rather than any term. For example, if
|
||||
``search_fields`` is set to ``['child__name', 'child__age']``, and a
|
||||
user searches for ``'Jamal 17'``, parent rows will be returned only if
|
||||
there is a relationship to some 17-year-old child named Jamal, rather
|
||||
than also returning parents who merely have a younger or older child
|
||||
named Jamal in addition to some other 17-year-old.
|
||||
|
||||
See the :ref:`spanning-multi-valued-relationships` topic for more
|
||||
discussion of this difference.
|
||||
|
||||
.. attribute:: ModelAdmin.search_help_text
|
||||
|
||||
Set ``search_help_text`` to specify a descriptive text for the search box
|
||||
|
|
@ -1418,22 +1402,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
field, for example ``... OR UPPER("polls_choice"."votes"::text) = UPPER('4')``
|
||||
on PostgreSQL.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Searches using multiple search terms are now applied in a single call
|
||||
to ``filter()``, rather than in sequential ``filter()`` calls.
|
||||
|
||||
For multi-valued relationships, this means that rows from the related
|
||||
model must match all terms rather than any term. For example, if
|
||||
``search_fields`` is set to ``['child__name', 'child__age']``, and a
|
||||
user searches for ``'Jamal 17'``, parent rows will be returned only if
|
||||
there is a relationship to some 17-year-old child named Jamal, rather
|
||||
than also returning parents who merely have a younger or older child
|
||||
named Jamal in addition to some other 17-year-old.
|
||||
|
||||
See the :ref:`spanning-multi-valued-relationships` topic for more
|
||||
discussion of this difference.
|
||||
|
||||
.. _Solr: https://solr.apache.org
|
||||
.. _Haystack: https://haystacksearch.org
|
||||
|
||||
|
|
@ -1999,10 +1967,6 @@ Other methods
|
|||
Django view for the page that shows the modification history for a given
|
||||
model instance.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Pagination was added.
|
||||
|
||||
Unlike the hook-type ``ModelAdmin`` methods detailed in the previous section,
|
||||
these five methods are in reality designed to be invoked as Django views from
|
||||
the admin application URL dispatching handler to render the pages that deal
|
||||
|
|
@ -2725,11 +2689,6 @@ linked to the document in ``{% block dark-mode-vars %}``.
|
|||
|
||||
.. _prefers-color-scheme: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The dark mode variables were moved to a separate stylesheet and template
|
||||
block.
|
||||
|
||||
``AdminSite`` objects
|
||||
=====================
|
||||
|
||||
|
|
@ -2900,10 +2859,6 @@ Templates can override or extend base admin templates as described in
|
|||
You can override this method to change the default order on the admin index
|
||||
page.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``app_label`` argument was added.
|
||||
|
||||
.. method:: AdminSite.has_permission(request)
|
||||
|
||||
Returns ``True`` if the user for the given ``HttpRequest`` has permission
|
||||
|
|
|
|||
|
|
@ -12,12 +12,6 @@ in the admin change form. The ``formset:added`` and ``formset:removed`` events
|
|||
allow this. ``event.detail.formsetName`` is the formset the row belongs to.
|
||||
For the ``formset:added`` event, ``event.target`` is the newly added row.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, the event was a ``jQuery`` event with ``$row`` and
|
||||
``formsetName`` parameters. It is now a JavaScript ``CustomEvent`` with
|
||||
parameters set in ``event.detail``.
|
||||
|
||||
In your custom ``change_form.html`` template, extend the
|
||||
``admin_change_form_document_ready`` block and add the event listener code:
|
||||
|
||||
|
|
|
|||
|
|
@ -666,10 +666,6 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
|
|||
if it wasn't provided to :func:`~django.contrib.auth.authenticate`
|
||||
(which passes it on to the backend).
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``created`` argument was added.
|
||||
|
||||
.. method:: user_can_authenticate()
|
||||
|
||||
Returns whether the user is allowed to authenticate. This method
|
||||
|
|
|
|||
|
|
@ -659,8 +659,6 @@ Other Properties & Methods
|
|||
|
||||
.. method:: GEOSGeometry.make_valid()
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Returns a valid :class:`GEOSGeometry` equivalent, trying not to lose any of
|
||||
the input vertices. If the geometry is already valid, it is returned
|
||||
untouched. This is similar to the
|
||||
|
|
@ -680,10 +678,6 @@ Other Properties & Methods
|
|||
>>> print(g)
|
||||
MULTIPOINT (2 2, 1 1, 0 0)
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``clone`` argument was added.
|
||||
|
||||
``Point``
|
||||
---------
|
||||
|
||||
|
|
|
|||
|
|
@ -78,8 +78,6 @@ General-purpose aggregation functions
|
|||
``BitXor``
|
||||
----------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
.. class:: BitXor(expression, filter=None, default=None, **extra)
|
||||
|
||||
Returns an ``int`` of the bitwise ``XOR`` of all non-null input values, or
|
||||
|
|
|
|||
|
|
@ -30,11 +30,6 @@ PostgreSQL supports additional data integrity constraints available from the
|
|||
Exclusion constraints are checked during the :ref:`model validation
|
||||
<validating-objects>`.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, exclusion constraints were not checked during model
|
||||
validation.
|
||||
|
||||
``name``
|
||||
--------
|
||||
|
||||
|
|
@ -71,10 +66,6 @@ For example::
|
|||
|
||||
creates an exclusion constraint on ``circle`` using ``circle_ops``.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for the ``OpClass()`` expression was added.
|
||||
|
||||
.. _operator class: https://www.postgresql.org/docs/current/indexes-opclass.html
|
||||
|
||||
``index_type``
|
||||
|
|
@ -142,11 +133,6 @@ used for queries that select only included fields
|
|||
``include`` is supported for GiST indexes. PostgreSQL 14+ also supports
|
||||
``include`` for SP-GiST indexes.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for covering exclusion constraints using SP-GiST indexes on
|
||||
PostgreSQL 14+ was added.
|
||||
|
||||
``opclasses``
|
||||
-------------
|
||||
|
||||
|
|
@ -176,8 +162,6 @@ creates an exclusion constraint on ``circle`` using ``circle_ops``.
|
|||
``violation_error_message``
|
||||
---------------------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
The error message used when ``ValidationError`` is raised during
|
||||
:ref:`model validation <validating-objects>`. Defaults to
|
||||
:attr:`.BaseConstraint.violation_error_message`.
|
||||
|
|
|
|||
|
|
@ -586,8 +586,6 @@ the ``default_bounds`` argument.
|
|||
|
||||
.. attribute:: DecimalRangeField.default_bounds
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Optional. The value of ``bounds`` for list and tuple inputs. The
|
||||
default is lower bound included, upper bound excluded, that is ``[)``
|
||||
(see the PostgreSQL documentation for details about
|
||||
|
|
@ -606,8 +604,6 @@ the ``default_bounds`` argument.
|
|||
|
||||
.. attribute:: DateTimeRangeField.default_bounds
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Optional. The value of ``bounds`` for list and tuple inputs. The
|
||||
default is lower bound included, upper bound excluded, that is ``[)``
|
||||
(see the PostgreSQL documentation for details about
|
||||
|
|
|
|||
|
|
@ -133,10 +133,6 @@ available from the ``django.contrib.postgres.indexes`` module.
|
|||
Provide an integer value from 10 to 100 to the fillfactor_ parameter to
|
||||
tune how packed the index pages will be. PostgreSQL's default is 90.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for covering SP-GiST indexes on PostgreSQL 14+ was added.
|
||||
|
||||
.. _fillfactor: https://www.postgresql.org/docs/current/sql-createindex.html#SQL-CREATEINDEX-STORAGE-PARAMETERS
|
||||
|
||||
``OpClass()`` expressions
|
||||
|
|
@ -178,8 +174,4 @@ available from the ``django.contrib.postgres.indexes`` module.
|
|||
|
||||
creates an exclusion constraint on ``circle`` using ``circle_ops``.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for exclusion constraints was added.
|
||||
|
||||
.. _operator class: https://www.postgresql.org/docs/current/indexes-opclass.html
|
||||
|
|
|
|||
|
|
@ -296,8 +296,6 @@ Note:
|
|||
|
||||
.. method:: Sitemap.get_latest_lastmod()
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
**Optional.** A method that returns the latest value returned by
|
||||
:attr:`~Sitemap.lastmod`. This function is used to add the ``lastmod``
|
||||
attribute to :ref:`Sitemap index context
|
||||
|
|
@ -465,10 +463,6 @@ with a caching decorator -- you must name your sitemap view and pass
|
|||
{'sitemaps': sitemaps}, name='sitemaps'),
|
||||
]
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Use of the ``Last-Modified`` header was added.
|
||||
|
||||
Template customization
|
||||
======================
|
||||
|
||||
|
|
@ -516,11 +510,6 @@ attributes:
|
|||
- ``lastmod``: Populated by the :meth:`~Sitemap.get_latest_lastmod`
|
||||
method for each sitemap.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The context was changed to a list of objects with ``location`` and optional
|
||||
``lastmod`` attributes.
|
||||
|
||||
Sitemap
|
||||
-------
|
||||
|
||||
|
|
|
|||
|
|
@ -330,10 +330,6 @@ argument. For example::
|
|||
manifest_storage = StaticFilesStorage(location=settings.BASE_DIR)
|
||||
super().__init__(*args, manifest_storage=manifest_storage, **kwargs)
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for finding paths in CSS source map comments was added.
|
||||
|
||||
.. versionchanged:: 4.2
|
||||
|
||||
Support for finding paths to JavaScript modules in ``import`` and
|
||||
|
|
|
|||
|
|
@ -82,10 +82,6 @@ The CSRF protection is based on the following things:
|
|||
Expanding the accepted referers beyond the current host or cookie domain can
|
||||
be done with the :setting:`CSRF_TRUSTED_ORIGINS` setting.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, the CSRF cookie value was masked.
|
||||
|
||||
This ensures that only forms that have originated from trusted domains can be
|
||||
used to POST data back.
|
||||
|
||||
|
|
|
|||
|
|
@ -72,10 +72,6 @@ connections, e.g. after database server restart. The health check is performed
|
|||
only once per request and only if the database is being accessed during the
|
||||
handling of the request.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The :setting:`CONN_HEALTH_CHECKS` setting was added.
|
||||
|
||||
Caveats
|
||||
~~~~~~~
|
||||
|
||||
|
|
@ -367,11 +363,6 @@ If you need to specify such values, reset the sequence afterward to avoid
|
|||
reusing a value that's already in the table. The :djadmin:`sqlsequencereset`
|
||||
management command generates the SQL statements to do that.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, PostgreSQL’s ``SERIAL`` data type was used instead of
|
||||
identity columns.
|
||||
|
||||
.. _sequence: https://www.postgresql.org/docs/current/sql-createsequence.html
|
||||
|
||||
Test database templates
|
||||
|
|
|
|||
|
|
@ -715,8 +715,6 @@ migrations are detected.
|
|||
|
||||
.. django-admin-option:: --scriptable
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Diverts log output and input prompts to ``stderr``, writing only paths of
|
||||
generated migration files to ``stdout``.
|
||||
|
||||
|
|
@ -805,8 +803,6 @@ detected.
|
|||
|
||||
.. django-admin-option:: --prune
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Deletes nonexistent migrations from the ``django_migrations`` table. This is
|
||||
useful when migration files replaced by a squashed migration have been removed.
|
||||
See :ref:`migration-squashing` for more details.
|
||||
|
|
@ -814,8 +810,6 @@ See :ref:`migration-squashing` for more details.
|
|||
``optimizemigration``
|
||||
---------------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
.. django-admin:: optimizemigration app_label migration_name
|
||||
|
||||
Optimizes the operations for the named migration and overrides the existing
|
||||
|
|
@ -1961,8 +1955,6 @@ See :doc:`/howto/custom-management-commands` for how to add customized actions.
|
|||
Black formatting
|
||||
----------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
The Python files created by :djadmin:`startproject`, :djadmin:`startapp`,
|
||||
:djadmin:`optimizemigration`, :djadmin:`makemigrations`, and
|
||||
:djadmin:`squashmigrations` are formatted using the ``black`` command if it is
|
||||
|
|
|
|||
|
|
@ -539,11 +539,6 @@ By default, a property returning the value of the renderer's
|
|||
as a string template name in order to override that for a particular form
|
||||
class.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions ``template_name`` defaulted to the string value
|
||||
``'django/forms/default.html'``.
|
||||
|
||||
``render()``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -604,14 +599,10 @@ template name.
|
|||
|
||||
.. attribute:: Form.template_name_div
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
The template used by ``as_div()``. Default: ``'django/forms/div.html'``.
|
||||
|
||||
.. method:: Form.as_div()
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
``as_div()`` renders the form as a series of ``<div>`` elements, with each
|
||||
``<div>`` containing one field, such as:
|
||||
|
||||
|
|
@ -1196,8 +1187,6 @@ Attributes of ``BoundField``
|
|||
|
||||
.. attribute:: BoundField.use_fieldset
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Returns the value of this BoundField widget's ``use_fieldset`` attribute.
|
||||
|
||||
.. attribute:: BoundField.widget_type
|
||||
|
|
@ -1292,14 +1281,8 @@ Methods of ``BoundField``
|
|||
overriding the default template, see also
|
||||
:ref:`overriding-built-in-form-templates`.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``tag`` argument was added.
|
||||
|
||||
.. method:: BoundField.legend_tag(contents=None, attrs=None, label_suffix=None)
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Calls :meth:`.label_tag` with ``tag='legend'`` to render the label with
|
||||
``<legend>`` tags. This is useful when rendering radio and multiple
|
||||
checkbox widgets where ``<legend>`` may be more appropriate than a
|
||||
|
|
|
|||
|
|
@ -527,10 +527,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
|
||||
Limit valid inputs to an integral multiple of ``step_size``.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``step_size`` argument was added.
|
||||
|
||||
``DurationField``
|
||||
-----------------
|
||||
|
||||
|
|
@ -662,8 +658,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
|
||||
.. attribute:: step_size
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Limit valid inputs to an integral multiple of ``step_size``.
|
||||
|
||||
``GenericIPAddressField``
|
||||
|
|
@ -797,8 +791,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
|
||||
.. attribute:: step_size
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Limit valid inputs to an integral multiple of ``step_size``.
|
||||
|
||||
``JSONField``
|
||||
|
|
|
|||
|
|
@ -72,10 +72,6 @@ Model Form API reference. For introductory material about model forms, see the
|
|||
|
||||
See :ref:`model-formsets` for example usage.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``edit_only`` argument was added.
|
||||
|
||||
``inlineformset_factory``
|
||||
=========================
|
||||
|
||||
|
|
@ -89,7 +85,3 @@ Model Form API reference. For introductory material about model forms, see the
|
|||
the ``parent_model``, you must specify a ``fk_name``.
|
||||
|
||||
See :ref:`inline-formsets` for example usage.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``edit_only`` argument was added.
|
||||
|
|
|
|||
|
|
@ -49,8 +49,6 @@ should return a rendered templates (as a string) or raise
|
|||
|
||||
.. attribute:: form_template_name
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
The default name of the template to use to render a form.
|
||||
|
||||
Defaults to ``"django/forms/default.html"``, which is a proxy for
|
||||
|
|
@ -64,8 +62,6 @@ should return a rendered templates (as a string) or raise
|
|||
|
||||
.. attribute:: formset_template_name
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
The default name of the template to use to render a formset.
|
||||
|
||||
Defaults to ``"django/forms/formsets/default.html"``, which is a proxy
|
||||
|
|
@ -111,8 +107,6 @@ If you want to render templates with customizations from your
|
|||
|
||||
.. class:: DjangoDivFormRenderer
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Subclass of :class:`DjangoTemplates` that specifies
|
||||
:attr:`~BaseRenderer.form_template_name` and
|
||||
:attr:`~BaseRenderer.formset_template_name` as ``"django/forms/div.html"`` and
|
||||
|
|
@ -147,8 +141,6 @@ widgets due to their usage of Django template tags.
|
|||
|
||||
.. class:: Jinja2DivFormRenderer
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
A transitional renderer as per :class:`DjangoDivFormRenderer` above, but
|
||||
subclassing :class:`Jinja2` for use with the Jinja2 backend.
|
||||
|
||||
|
|
|
|||
|
|
@ -318,8 +318,6 @@ foundation for custom widgets.
|
|||
|
||||
.. attribute:: Widget.use_fieldset
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
An attribute to identify if the widget should be grouped in a
|
||||
``<fieldset>`` with a ``<legend>`` when rendered. Defaults to ``False``
|
||||
but is ``True`` when the widget contains multiple ``<input>`` tags such as
|
||||
|
|
|
|||
|
|
@ -244,8 +244,6 @@ Removes the index named ``name`` from the model with ``model_name``.
|
|||
``RenameIndex``
|
||||
---------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
.. class:: RenameIndex(model_name, new_name, old_name=None, old_fields=None)
|
||||
|
||||
Renames an index in the database table for the model with ``model_name``.
|
||||
|
|
|
|||
|
|
@ -45,10 +45,6 @@ option.
|
|||
``django.db.models`` logger, like *"Got a database error calling check() on
|
||||
…"* to confirm it's validated properly.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, constraints were not checked during model validation.
|
||||
|
||||
``BaseConstraint``
|
||||
==================
|
||||
|
||||
|
|
@ -71,8 +67,6 @@ constraint.
|
|||
``violation_error_message``
|
||||
---------------------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
.. attribute:: BaseConstraint.violation_error_message
|
||||
|
||||
The error message used when ``ValidationError`` is raised during
|
||||
|
|
@ -82,8 +76,6 @@ The error message used when ``ValidationError`` is raised during
|
|||
``validate()``
|
||||
--------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
.. method:: BaseConstraint.validate(model, instance, exclude=None, using=DEFAULT_DB_ALIAS)
|
||||
|
||||
Validates that the constraint, defined on ``model``, is respected on the
|
||||
|
|
@ -122,10 +114,6 @@ ensures the age field is never less than 18.
|
|||
|
||||
CheckConstraint(check=Q(age__gte=18) | Q(age__isnull=True), name='age_gte_18')
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``violation_error_message`` argument was added.
|
||||
|
||||
``UniqueConstraint``
|
||||
====================
|
||||
|
||||
|
|
@ -253,8 +241,6 @@ creates a unique index on ``username`` using ``varchar_pattern_ops``.
|
|||
``violation_error_message``
|
||||
---------------------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
.. attribute:: UniqueConstraint.violation_error_message
|
||||
|
||||
The error message used when ``ValidationError`` is raised during
|
||||
|
|
|
|||
|
|
@ -784,10 +784,6 @@ and second row.
|
|||
The ``frame`` parameter specifies which other rows that should be used in the
|
||||
computation. See :ref:`window-frames` for details.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for ``order_by`` by field name references was added.
|
||||
|
||||
For example, to annotate each movie with the average rating for the movies by
|
||||
the same studio in the same genre and release year::
|
||||
|
||||
|
|
@ -1067,11 +1063,6 @@ calling the appropriate methods on the wrapped expression.
|
|||
``nulls_first`` and ``nulls_last`` define how null values are sorted.
|
||||
See :ref:`using-f-to-sort-null-values` for example usage.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, ``nulls_first`` and ``nulls_last`` defaulted to
|
||||
``False``.
|
||||
|
||||
.. deprecated:: 4.1
|
||||
|
||||
Passing ``nulls_first=False`` or ``nulls_last=False`` to ``asc()``
|
||||
|
|
@ -1084,11 +1075,6 @@ calling the appropriate methods on the wrapped expression.
|
|||
``nulls_first`` and ``nulls_last`` define how null values are sorted.
|
||||
See :ref:`using-f-to-sort-null-values` for example usage.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, ``nulls_first`` and ``nulls_last`` defaulted to
|
||||
``False``.
|
||||
|
||||
.. deprecated:: 4.1
|
||||
|
||||
Passing ``nulls_first=False`` or ``nulls_last=False`` to ``desc()``
|
||||
|
|
|
|||
|
|
@ -219,8 +219,4 @@ See the PostgreSQL documentation for more details about `covering indexes`_.
|
|||
covering :class:`SP-GiST indexes
|
||||
<django.contrib.postgres.indexes.SpGistIndex>`.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for covering SP-GiST indexes with PostgreSQL 14+ was added.
|
||||
|
||||
.. _covering indexes: https://www.postgresql.org/docs/current/indexes-index-only-scans.html
|
||||
|
|
|
|||
|
|
@ -229,11 +229,6 @@ validation errors yourself, or if you have excluded fields from the
|
|||
``django.db.models`` logger, like *"Got a database error calling check() on
|
||||
…"* to confirm it's validated properly.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, constraints were not checked during the model
|
||||
validation.
|
||||
|
||||
.. method:: Model.full_clean(exclude=None, validate_unique=True, validate_constraints=True)
|
||||
|
||||
This method calls :meth:`Model.clean_fields()`, :meth:`Model.clean()`,
|
||||
|
|
@ -263,14 +258,6 @@ models. For example::
|
|||
|
||||
The first step ``full_clean()`` performs is to clean each individual field.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``validate_constraints`` argument was added.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
An ``exclude`` value is now converted to a ``set`` rather than a ``list``.
|
||||
|
||||
.. method:: Model.clean_fields(exclude=None)
|
||||
|
||||
This method will validate all fields on your model. The optional ``exclude``
|
||||
|
|
@ -391,15 +378,8 @@ the fields you provided will not be checked.
|
|||
|
||||
Finally, ``full_clean()`` will check any other constraints on your model.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, :class:`~django.db.models.UniqueConstraint`\s were
|
||||
validated by ``validate_unique()``.
|
||||
|
||||
.. method:: Model.validate_constraints(exclude=None)
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
This method validates all constraints defined in
|
||||
:attr:`Meta.constraints <django.db.models.Options.constraints>`. The
|
||||
optional ``exclude`` argument allows you to provide a ``set`` of field names to
|
||||
|
|
|
|||
|
|
@ -43,10 +43,6 @@ You can evaluate a ``QuerySet`` in the following ways:
|
|||
Both synchronous and asynchronous iterators of QuerySets share the same
|
||||
underlying cache.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for asynchronous iteration was added.
|
||||
|
||||
* **Slicing.** As explained in :ref:`limiting-querysets`, a ``QuerySet`` can
|
||||
be sliced, using Python's array-slicing syntax. Slicing an unevaluated
|
||||
``QuerySet`` usually returns another unevaluated ``QuerySet``, but Django
|
||||
|
|
@ -1250,10 +1246,8 @@ could be generated, which, depending on the database, might have performance
|
|||
problems of its own when it comes to parsing or executing the SQL query. Always
|
||||
profile for your use case!
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
If you use ``iterator()`` to run the query, ``prefetch_related()``
|
||||
calls will only be observed if a value for ``chunk_size`` is provided.
|
||||
If you use ``iterator()`` to run the query, ``prefetch_related()`` calls will
|
||||
only be observed if a value for ``chunk_size`` is provided.
|
||||
|
||||
You can use the :class:`~django.db.models.Prefetch` object to further control
|
||||
the prefetch operation.
|
||||
|
|
@ -1955,8 +1949,6 @@ may be generated.
|
|||
XOR (``^``)
|
||||
~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Combines two ``QuerySet``\s using the SQL ``XOR`` operator.
|
||||
|
||||
The following are equivalent::
|
||||
|
|
@ -2003,10 +1995,6 @@ this reason, each has a corresponding asynchronous version with an ``a`` prefix
|
|||
There is usually no difference in behavior apart from their asynchronous
|
||||
nature, but any differences are noted below next to each method.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The asynchronous versions of each method, prefixed with ``a`` was added.
|
||||
|
||||
``get()``
|
||||
~~~~~~~~~
|
||||
|
||||
|
|
@ -2053,10 +2041,6 @@ can use :exc:`django.core.exceptions.ObjectDoesNotExist` to handle
|
|||
except ObjectDoesNotExist:
|
||||
print("Either the blog or entry doesn't exist.")
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``aget()`` method was added.
|
||||
|
||||
``create()``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2084,10 +2068,6 @@ database, a call to ``create()`` will fail with an
|
|||
:exc:`~django.db.IntegrityError` since primary keys must be unique. Be
|
||||
prepared to handle the exception if you are using manual primary keys.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``acreate()`` method was added.
|
||||
|
||||
``get_or_create()``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2216,10 +2196,6 @@ whenever a request to a page has a side effect on your data. For more, see
|
|||
chapter because it isn't related to that book, but it can't create it either
|
||||
because ``title`` field should be unique.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``aget_or_create()`` method was added.
|
||||
|
||||
``update_or_create()``
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2273,10 +2249,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:: 4.1
|
||||
|
||||
``aupdate_or_create()`` method was added.
|
||||
|
||||
.. versionchanged:: 4.2
|
||||
|
||||
In older versions, ``update_or_create()`` didn't specify ``update_fields``
|
||||
|
|
@ -2354,14 +2326,6 @@ support it).
|
|||
.. _MySQL documentation: https://dev.mysql.com/doc/refman/en/sql-mode.html#ignore-strict-comparison
|
||||
.. _MariaDB documentation: https://mariadb.com/kb/en/ignore/
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``update_conflicts``, ``update_fields``, and ``unique_fields``
|
||||
parameters were added to support updating fields when a row insertion fails
|
||||
on conflict.
|
||||
|
||||
``abulk_create()`` method was added.
|
||||
|
||||
``bulk_update()``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2407,10 +2371,6 @@ The ``batch_size`` parameter controls how many objects are saved in a single
|
|||
query. The default is to update all objects in one batch, except for SQLite
|
||||
and Oracle which have restrictions on the number of variables used in a query.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``abulk_update()`` method was added.
|
||||
|
||||
``count()``
|
||||
~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2443,10 +2403,6 @@ database query like ``count()`` would.
|
|||
If the queryset has already been fully retrieved, ``count()`` will use that
|
||||
length rather than perform an extra database query.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``acount()`` method was added.
|
||||
|
||||
``in_bulk()``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2482,10 +2438,6 @@ Example::
|
|||
|
||||
If you pass ``in_bulk()`` an empty list, you'll get an empty dictionary.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``ain_bulk()`` method was added.
|
||||
|
||||
``iterator()``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2532,12 +2484,6 @@ value for ``chunk_size`` will result in Django using an implicit default of
|
|||
Depending on the database backend, query results will either be loaded all at
|
||||
once or streamed from the database using server-side cursors.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for prefetching related objects was added to ``iterator()``.
|
||||
|
||||
``aiterator()`` method was added.
|
||||
|
||||
.. deprecated:: 4.1
|
||||
|
||||
Using ``iterator()`` on a queryset that prefetches related objects without
|
||||
|
|
@ -2640,10 +2586,6 @@ readability.
|
|||
|
||||
Entry.objects.filter(pub_date__isnull=False).latest('pub_date')
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``alatest()`` method was added.
|
||||
|
||||
``earliest()``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2655,10 +2597,6 @@ readability.
|
|||
Works otherwise like :meth:`~django.db.models.query.QuerySet.latest` except
|
||||
the direction is changed.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``aearliest()`` method was added.
|
||||
|
||||
``first()``
|
||||
~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2684,10 +2622,6 @@ equivalent to the above example::
|
|||
except IndexError:
|
||||
p = None
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``afirst()`` method was added.
|
||||
|
||||
``last()``
|
||||
~~~~~~~~~~
|
||||
|
||||
|
|
@ -2698,10 +2632,6 @@ equivalent to the above example::
|
|||
|
||||
Works like :meth:`first()`, but returns the last object in the queryset.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``alast()`` method was added.
|
||||
|
||||
``aggregate()``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2741,10 +2671,6 @@ control the name of the aggregation value that is returned::
|
|||
For an in-depth discussion of aggregation, see :doc:`the topic guide on
|
||||
Aggregation </topics/db/aggregation>`.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``aaggregate()`` method was added.
|
||||
|
||||
``exists()``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2781,10 +2707,6 @@ more overall work (one query for the existence check plus an extra one to later
|
|||
retrieve the results) than using ``bool(some_queryset)``, which retrieves the
|
||||
results and then checks if any were returned.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``aexists()`` method was added.
|
||||
|
||||
``contains()``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2815,10 +2737,6 @@ know that it will be at some point, then using ``some_queryset.contains(obj)``
|
|||
will make an additional database query, generally resulting in slower overall
|
||||
performance.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``acontains()`` method was added.
|
||||
|
||||
``update()``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -2896,10 +2814,6 @@ update a bunch of records for a model that has a custom
|
|||
e.comments_on = False
|
||||
e.save()
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``aupdate()`` method was added.
|
||||
|
||||
Ordered queryset
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
@ -2971,10 +2885,6 @@ ForeignKeys which are set to :attr:`~django.db.models.ForeignKey.on_delete`
|
|||
Note that the queries generated in object deletion is an implementation
|
||||
detail subject to change.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``adelete()`` method was added.
|
||||
|
||||
``as_manager()``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -3033,10 +2943,6 @@ adverse effects on your database. For example, the ``ANALYZE`` flag supported
|
|||
by MariaDB, MySQL 8.0.18+, and PostgreSQL could result in changes to data if
|
||||
there are triggers or if a function is called, even for a ``SELECT`` query.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``aexplain()`` method was added.
|
||||
|
||||
.. _field-lookups:
|
||||
|
||||
``Field`` lookups
|
||||
|
|
@ -3982,10 +3888,6 @@ or annotation. They make it possible to define and reuse conditions, and
|
|||
combine them using operators such as ``|`` (``OR``), ``&`` (``AND``), and ``^``
|
||||
(``XOR``). See :ref:`complex-lookups-with-q`.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for the ``^`` (``XOR``) operator was added.
|
||||
|
||||
``Prefetch()`` objects
|
||||
----------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -120,10 +120,6 @@ Related objects reference
|
|||
needed. You can use callables as values in the ``through_defaults``
|
||||
dictionary.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
``acreate()`` method was added.
|
||||
|
||||
.. method:: remove(*objs, bulk=True)
|
||||
.. method:: aremove(*objs, bulk=True)
|
||||
|
||||
|
|
|
|||
|
|
@ -857,11 +857,6 @@ Methods
|
|||
number of seconds, or ``None`` (default) if the cookie should last only
|
||||
as long as the client's browser session. If ``expires`` is not specified,
|
||||
it will be calculated.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for ``timedelta`` objects was added.
|
||||
|
||||
* ``expires`` should either be a string in the format
|
||||
``"Wdy, DD-Mon-YY HH:MM:SS GMT"`` or a ``datetime.datetime`` object
|
||||
in UTC. If ``expires`` is a ``datetime`` object, the ``max_age``
|
||||
|
|
|
|||
|
|
@ -82,8 +82,6 @@ Removes ``index`` from ``model``’s table.
|
|||
``rename_index()``
|
||||
------------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
.. method:: BaseDatabaseSchemaEditor.rename_index(model, old_index, new_index)
|
||||
|
||||
Renames ``old_index`` from ``model``’s table to ``new_index``.
|
||||
|
|
|
|||
|
|
@ -348,8 +348,6 @@ See :setting:`SESSION_COOKIE_HTTPONLY` for details on ``HttpOnly``.
|
|||
``CSRF_COOKIE_MASKED``
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Default: ``False``
|
||||
|
||||
Whether to mask the CSRF cookie. See
|
||||
|
|
@ -625,8 +623,6 @@ behavior — and ``None`` for unlimited :ref:`persistent database connections
|
|||
``CONN_HEALTH_CHECKS``
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Default: ``False``
|
||||
|
||||
If set to ``True``, existing :ref:`persistent database connections
|
||||
|
|
@ -2311,8 +2307,6 @@ passwords of users and key rotation will not affect them.
|
|||
``SECRET_KEY_FALLBACKS``
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Default: ``[]``
|
||||
|
||||
A list of fallback secret keys for a particular Django installation. These are
|
||||
|
|
@ -2444,11 +2438,6 @@ in via HTTPS) when:
|
|||
* its initial, leftmost value is ``'https'`` in the case of a comma-separated
|
||||
list of protocols (e.g. ``'https,http,http'``).
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for a comma-separated list of protocols in the header value was
|
||||
added.
|
||||
|
||||
You should *only* set this setting if you control your proxy or have some other
|
||||
guarantee that it sets/strips this header appropriately.
|
||||
|
||||
|
|
|
|||
|
|
@ -204,7 +204,6 @@ Arguments sent with this signal:
|
|||
The database alias being used.
|
||||
|
||||
``origin``
|
||||
.. versionadded:: 4.1
|
||||
|
||||
The origin of the deletion being the instance of a ``Model`` or
|
||||
``QuerySet`` class.
|
||||
|
|
@ -234,7 +233,6 @@ Arguments sent with this signal:
|
|||
The database alias being used.
|
||||
|
||||
``origin``
|
||||
.. versionadded:: 4.1
|
||||
|
||||
The origin of the deletion being the instance of a ``Model`` or
|
||||
``QuerySet`` class.
|
||||
|
|
|
|||
|
|
@ -102,11 +102,6 @@ overridden by what's passed by
|
|||
These loaders are then wrapped in
|
||||
:class:`django.template.loaders.cached.Loader`.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, the cached template loader was only enabled by
|
||||
default when ``DEBUG`` was ``False``.
|
||||
|
||||
See :ref:`template-loaders` for details.
|
||||
|
||||
* ``string_if_invalid`` is the output, as a string, that the template
|
||||
|
|
@ -949,12 +944,6 @@ loaders that come with Django:
|
|||
information, see :ref:`template tag thread safety considerations
|
||||
<template_tag_thread_safety>`.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The cached template loader was enabled whenever ``OPTIONS['loaders']``
|
||||
is not specified. Previously it was only enabled when ``DEBUG`` was
|
||||
``False``.
|
||||
|
||||
``django.template.loaders.locmem.Loader``
|
||||
|
||||
.. class:: locmem.Loader
|
||||
|
|
|
|||
|
|
@ -1867,10 +1867,6 @@ This is compatible with a strict Content Security Policy that prohibits in-page
|
|||
script execution. It also maintains a clean separation between passive data and
|
||||
executable code.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, the HTML "id" was a required argument.
|
||||
|
||||
.. templatefilter:: last
|
||||
|
||||
``last``
|
||||
|
|
|
|||
|
|
@ -129,15 +129,11 @@ If the URL does not resolve, the function raises a
|
|||
|
||||
.. attribute:: ResolverMatch.captured_kwargs
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
The captured keyword arguments that would be passed to the view
|
||||
function, as parsed from the URL.
|
||||
|
||||
.. attribute:: ResolverMatch.extra_kwargs
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
The additional keyword arguments that would be passed to the view
|
||||
function.
|
||||
|
||||
|
|
|
|||
|
|
@ -670,10 +670,6 @@ escaping HTML.
|
|||
serialize the data. See :ref:`JSON serialization
|
||||
<serialization-formats-json>` for more details about this serializer.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, the ``element_id`` argument was required.
|
||||
|
||||
.. versionchanged:: 4.2
|
||||
|
||||
The ``encoder`` argument was added.
|
||||
|
|
|
|||
|
|
@ -337,8 +337,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
``StepValueValidator``
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
.. class:: StepValueValidator(limit_value, message=None)
|
||||
|
||||
Raises a :exc:`~django.core.exceptions.ValidationError` with a code of
|
||||
|
|
|
|||
|
|
@ -76,8 +76,6 @@ corruption.
|
|||
Queries & the ORM
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
With some exceptions, Django can run ORM queries asynchronously as well::
|
||||
|
||||
async for author in Author.objects.filter(name__startswith="A"):
|
||||
|
|
|
|||
|
|
@ -134,8 +134,6 @@ information, the client may or may not download the full object list.
|
|||
Asynchronous class-based views
|
||||
==============================
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
As well as the synchronous (``def``) method handlers already shown, ``View``
|
||||
subclasses may define asynchronous (``async def``) method handlers to leverage
|
||||
asynchronous code using ``await``::
|
||||
|
|
|
|||
|
|
@ -857,8 +857,6 @@ being evaluated and therefore populate the cache::
|
|||
Asynchronous queries
|
||||
====================
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
If you are writing asynchronous views or code, you cannot use the ORM for
|
||||
queries in quite the way we have described above, as you cannot call *blocking*
|
||||
synchronous code from asynchronous code - it will block up the event loop
|
||||
|
|
@ -873,8 +871,6 @@ results, you can use asynchronous iteration (``async for``) instead.
|
|||
Query iteration
|
||||
---------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
The default way of iterating over a query - with ``for`` - will result in a
|
||||
blocking database query behind the scenes as Django loads the results at
|
||||
iteration time. To fix this, you can swap to ``async for``::
|
||||
|
|
@ -895,8 +891,6 @@ read the next section.
|
|||
``QuerySet`` and manager methods
|
||||
--------------------------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Some methods on managers and querysets - like ``get()`` and ``first()`` - force
|
||||
execution of the queryset and are blocking. Some, like ``filter()`` and
|
||||
``exclude()``, don't force execution and so are safe to run from asynchronous
|
||||
|
|
@ -938,8 +932,6 @@ the whole expression in order to call it in an asynchronous-friendly way.
|
|||
Transactions
|
||||
------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Transactions are **not** currently supported with asynchronous queries and
|
||||
updates. You will find that trying to use one raises
|
||||
``SynchronousOnlyOperation``.
|
||||
|
|
@ -1319,10 +1311,6 @@ precede the definition of any keyword arguments. For example::
|
|||
The :source:`OR lookups examples <tests/or_lookups/tests.py>` in Django's
|
||||
unit tests show some possible uses of ``Q``.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
Support for the ``^`` (``XOR``) operator was added.
|
||||
|
||||
Comparing objects
|
||||
=================
|
||||
|
||||
|
|
|
|||
|
|
@ -238,11 +238,6 @@ Django provides a single API to control database transactions.
|
|||
is especially important if you're using :func:`atomic` in long-running
|
||||
processes, outside of Django's request / response cycle.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, the durability check was disabled in
|
||||
:class:`django.test.TestCase`.
|
||||
|
||||
Autocommit
|
||||
==========
|
||||
|
||||
|
|
|
|||
|
|
@ -317,10 +317,6 @@ And here is a custom error message::
|
|||
>>> formset.non_form_errors()
|
||||
['Sorry, something went wrong.']
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``'too_few_forms'`` and ``'too_many_forms'`` keys were added.
|
||||
|
||||
Custom formset validation
|
||||
-------------------------
|
||||
|
||||
|
|
@ -804,16 +800,8 @@ Formsets have the following attributes and methods associated with rendering:
|
|||
then each form in the formset as per the template defined by the form's
|
||||
:attr:`~django.forms.Form.template_name`.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions ``template_name`` defaulted to the string value
|
||||
``'django/forms/formset/default.html'``.
|
||||
|
||||
|
||||
.. attribute:: BaseFormSet.template_name_div
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
The name of the template used when calling :meth:`.as_div`. By default this
|
||||
is ``"django/forms/formsets/div.html"``. This template renders the
|
||||
formset's management form and then each form in the formset as per the
|
||||
|
|
|
|||
|
|
@ -552,11 +552,6 @@ the :meth:`.Form.render`. Here's an example of this being used in a view::
|
|||
|
||||
See :ref:`ref-forms-api-outputting-html` for more details.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ability to set the default ``form_template_name`` on the form renderer
|
||||
was added.
|
||||
|
||||
Form rendering options
|
||||
----------------------
|
||||
|
||||
|
|
@ -754,15 +749,11 @@ Useful attributes on ``{{ field }}`` include:
|
|||
|
||||
``{{ field.legend_tag }}``
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Similar to ``field.label_tag`` but uses a ``<legend>`` tag in place of
|
||||
``<label>``, for widgets with multiple inputs wrapped in a ``<fieldset>``.
|
||||
|
||||
``{{ field.use_fieldset }}``
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
This attribute is ``True`` if the form field's widget contains multiple
|
||||
inputs that should be semantically grouped in a ``<fieldset>`` with a
|
||||
``<legend>`` to improve accessibility. An example use in a template:
|
||||
|
|
|
|||
|
|
@ -118,11 +118,6 @@ If this last CSS definition were to be rendered, it would become the following H
|
|||
<link href="http://static.example.com/lo_res.css" media="tv,projector" rel="stylesheet">
|
||||
<link href="http://static.example.com/newspaper.css" media="print" rel="stylesheet">
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, the ``type="text/css"`` attribute is included in CSS
|
||||
links.
|
||||
|
||||
``js``
|
||||
------
|
||||
|
||||
|
|
@ -260,8 +255,6 @@ Or if :mod:`~django.contrib.staticfiles` is configured using the
|
|||
Paths as objects
|
||||
----------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Asset paths may also be given as hashable objects implementing an
|
||||
``__html__()`` method. The ``__html__()`` method is typically added using the
|
||||
:func:`~django.utils.html.html_safe` decorator. The object is responsible for
|
||||
|
|
|
|||
|
|
@ -995,8 +995,6 @@ of forms displayed (1000). In practice this is equivalent to no limit.
|
|||
Preventing new objects creation
|
||||
-------------------------------
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
Using the ``edit_only`` parameter, you can prevent creation of any new
|
||||
objects::
|
||||
|
||||
|
|
|
|||
|
|
@ -712,8 +712,6 @@ You must then transition the squashed migration to a normal migration by:
|
|||
|
||||
.. admonition:: Pruning references to deleted migrations
|
||||
|
||||
.. versionadded:: 4.1
|
||||
|
||||
If it is likely that you may reuse the name of a deleted migration in the
|
||||
future, you should remove references to it from Django’s migrations table
|
||||
with the :option:`migrate --prune` option.
|
||||
|
|
|
|||
|
|
@ -38,10 +38,6 @@ generate their own signed values.
|
|||
values will not be used to sign data, but if specified, they will be used to
|
||||
validate signed data and must be kept secure.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``SECRET_KEY_FALLBACKS`` setting was added.
|
||||
|
||||
Using the low-level API
|
||||
=======================
|
||||
|
||||
|
|
@ -111,10 +107,6 @@ generate signatures. You can use a different secret by passing it to the
|
|||
of additional values used to validate signed data, defaults to
|
||||
:setting:`SECRET_KEY_FALLBACKS`.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``fallback_keys`` argument was added.
|
||||
|
||||
.. deprecated:: 4.2
|
||||
|
||||
Support for passing positional arguments is deprecated.
|
||||
|
|
@ -247,7 +239,3 @@ and tuples) if you pass in a tuple, you will get a list from
|
|||
|
||||
Reverse of ``dumps()``, raises ``BadSignature`` if signature fails.
|
||||
Checks ``max_age`` (in seconds) if given.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
The ``fallback_keys`` argument was added.
|
||||
|
|
|
|||
|
|
@ -331,10 +331,6 @@ or an unexpected success). If all the tests pass, the return code is 0. This
|
|||
feature is useful if you're using the test-runner script in a shell script and
|
||||
need to test for success or failure at that level.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, the return code was 0 for unexpected successes.
|
||||
|
||||
.. _speeding-up-tests-auth-hashers:
|
||||
|
||||
Speeding up the tests
|
||||
|
|
|
|||
|
|
@ -1601,19 +1601,6 @@ your test suite.
|
|||
which means that ``errors='error message'`` is the same as
|
||||
``errors=['error message']``.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, using an empty error list with ``assertFormError()``
|
||||
would always pass, regardless of whether the field had any errors or
|
||||
not. Starting from Django 4.1, using ``errors=[]`` will only pass if
|
||||
the field actually has no errors.
|
||||
|
||||
Django 4.1 also changed the behavior of ``assertFormError()`` when a
|
||||
field has multiple errors. In older versions, if a field had multiple
|
||||
errors and you checked for only some of them, the test would pass.
|
||||
Starting from Django 4.1, the error list must be an exact match to the
|
||||
field's actual errors.
|
||||
|
||||
.. deprecated:: 4.1
|
||||
|
||||
Support for passing a response object and a form name to
|
||||
|
|
|
|||
Loading…
Reference in New Issue