mirror of
https://github.com/django/django.git
synced 2025-08-04 02:48:35 +00:00
Removed versionadded/changed annotations for 1.8.
This commit is contained in:
parent
48e7787db5
commit
54848a96dd
74 changed files with 44 additions and 852 deletions
|
@ -4,8 +4,6 @@ Conditional Expressions
|
|||
|
||||
.. currentmodule:: django.db.models.expressions
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Conditional expressions let you use :keyword:`if` ... :keyword:`elif` ...
|
||||
:keyword:`else` logic within filters, annotations, aggregations, and updates. A
|
||||
conditional expression evaluates a series of conditions for each row of a
|
||||
|
|
|
@ -5,8 +5,6 @@ Database Functions
|
|||
.. module:: django.db.models.functions
|
||||
:synopsis: Database Functions
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The classes documented below provide a way for users to use functions provided
|
||||
by the underlying database as annotations, aggregations, or filters in Django.
|
||||
Functions are also :doc:`expressions <expressions>`, so they can be used and
|
||||
|
|
|
@ -24,10 +24,6 @@ variables, and even other expressions.
|
|||
Some examples
|
||||
=============
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Some of the examples rely on functionality that is new in Django 1.8.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from django.db.models import F, Count
|
||||
|
@ -211,8 +207,6 @@ directly support ``output_field`` you will need to wrap the expression with
|
|||
``Func()`` expressions
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
``Func()`` expressions are the base type of all expressions that involve
|
||||
database functions like ``COALESCE`` and ``LOWER``, or aggregates like ``SUM``.
|
||||
They can be used directly::
|
||||
|
@ -322,18 +316,9 @@ should define the desired ``output_field``. For example, adding an
|
|||
``IntegerField()`` and a ``FloatField()`` together should probably have
|
||||
``output_field=FloatField()`` defined.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``output_field`` is a new parameter.
|
||||
|
||||
The ``**extra`` kwargs are ``key=value`` pairs that can be interpolated
|
||||
into the ``template`` attribute.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Aggregate functions can now use arithmetic and reference multiple
|
||||
model fields in a single function.
|
||||
|
||||
Creating your own Aggregate Functions
|
||||
-------------------------------------
|
||||
|
||||
|
@ -390,8 +375,6 @@ output value.
|
|||
|
||||
.. class:: ExpressionWrapper(expression, output_field)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
``ExpressionWrapper`` simply surrounds another expression and provides access
|
||||
to properties, such as ``output_field``, that may not be available on other
|
||||
expressions. ``ExpressionWrapper`` is necessary when using arithmetic on
|
||||
|
@ -401,8 +384,6 @@ expressions. ``ExpressionWrapper`` is necessary when using arithmetic on
|
|||
Conditional expressions
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Conditional expressions allow you to use :keyword:`if` ... :keyword:`elif` ...
|
||||
:keyword:`else` logic in queries. Django natively supports SQL ``CASE``
|
||||
expressions. For more details see :doc:`conditional-expressions`.
|
||||
|
@ -410,8 +391,6 @@ expressions. For more details see :doc:`conditional-expressions`.
|
|||
Raw SQL expressions
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. currentmodule:: django.db.models.expressions
|
||||
|
||||
.. class:: RawSQL(sql, params, output_field=None)
|
||||
|
|
|
@ -228,11 +228,6 @@ The default value is used when new model instances are created and a value
|
|||
isn't provided for the field. When the field is a primary key, the default is
|
||||
also used when the field is set to ``None``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The default wasn't used for ``None`` primary key values in previous
|
||||
versions.
|
||||
|
||||
``editable``
|
||||
------------
|
||||
|
||||
|
@ -574,8 +569,6 @@ when :attr:`~django.forms.Field.localize` is ``False`` or
|
|||
``DurationField``
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. class:: DurationField(**options)
|
||||
|
||||
A field for storing periods of time - modeled in Python by
|
||||
|
@ -597,11 +590,6 @@ SECOND(6)``. Otherwise a ``bigint`` of microseconds is used.
|
|||
A :class:`CharField` that checks that the value is a valid email address. It
|
||||
uses :class:`~django.core.validators.EmailValidator` to validate the input.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The default ``max_length`` was increased from 75 to 254 in order to be
|
||||
compliant with RFC3696/5321.
|
||||
|
||||
``FileField``
|
||||
-------------
|
||||
|
||||
|
@ -1079,8 +1067,6 @@ Like all :class:`CharField` subclasses, :class:`URLField` takes the optional
|
|||
``UUIDField``
|
||||
-------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. class:: UUIDField(**options)
|
||||
|
||||
A field for storing universally unique identifiers. Uses Python's
|
||||
|
@ -1757,8 +1743,6 @@ Field API reference
|
|||
|
||||
.. method:: from_db_value(value, expression, connection, context)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Converts a value as returned by the database to a Python object. It is
|
||||
the reverse of :meth:`get_prep_value`.
|
||||
|
||||
|
@ -1878,8 +1862,6 @@ Field API reference
|
|||
Field attribute reference
|
||||
=========================
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Every ``Field`` instance contains several attributes that allow
|
||||
introspecting its behavior. Use these attributes instead of ``isinstance``
|
||||
checks when you need to write code that depends on a field's functionality.
|
||||
|
|
|
@ -67,8 +67,6 @@ Customizing model loading
|
|||
|
||||
.. classmethod:: Model.from_db(db, field_names, values)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``from_db()`` method can be used to customize model instance creation
|
||||
when loading from the database.
|
||||
|
||||
|
@ -121,8 +119,6 @@ Refreshing objects from database
|
|||
|
||||
.. method:: Model.refresh_from_db(using=None, fields=None, **kwargs)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
If you need to reload a model's values from the database, you can use the
|
||||
``refresh_from_db()`` method. When this method is called without arguments the
|
||||
following is done:
|
||||
|
@ -178,8 +174,6 @@ all of the instance's fields when a deferred field is reloaded::
|
|||
|
||||
.. method:: Model.get_deferred_fields()
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
A helper method that returns a set containing the attribute names of all those
|
||||
fields that are currently deferred for this model.
|
||||
|
||||
|
@ -582,8 +576,6 @@ the data that's currently in the database.
|
|||
Django version N+1. Pickles should not be used as part of a long-term
|
||||
archival strategy.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Since pickle compatibility errors can be difficult to diagnose, such as
|
||||
silently corrupted objects, a ``RuntimeWarning`` is raised when you try to
|
||||
unpickle a model in a Django version that is different than the one in
|
||||
|
|
|
@ -141,8 +141,6 @@ Transform reference
|
|||
|
||||
.. attribute:: bilateral
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
A boolean indicating whether this transformation should apply to both
|
||||
``lhs`` and ``rhs``. Bilateral transformations will be applied to ``rhs`` in
|
||||
the same order as they appear in the lookup expression. By default it is set
|
||||
|
|
|
@ -18,15 +18,6 @@ Methods that it provides can be used to:
|
|||
* Retrieve all field instances of a model
|
||||
* Retrieve a single field instance of a model by name
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The Model ``_meta`` API has always existed as a Django internal, but
|
||||
wasn't formally documented and supported. As part of the effort to
|
||||
make this API public, some of the already existing API entry points
|
||||
have changed slightly. A :ref:`migration guide <migrating-old-meta-api>`
|
||||
has been provided to assist in converting your code to use the new,
|
||||
official API.
|
||||
|
||||
.. _model-meta-field-api:
|
||||
|
||||
Field access API
|
||||
|
@ -75,8 +66,6 @@ Retrieving all field instances of a model
|
|||
|
||||
.. method:: Options.get_fields(include_parents=True, include_hidden=False)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Returns a tuple of fields associated with a model. ``get_fields()`` accepts
|
||||
two parameters that can be used to control which fields are returned:
|
||||
|
||||
|
|
|
@ -100,8 +100,6 @@ Django quotes column and table names behind the scenes.
|
|||
|
||||
.. attribute:: Options.default_related_name
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The name that will be used by default for the relation from a related object
|
||||
back to this one. The default is ``<model_name>_set``.
|
||||
|
||||
|
|
|
@ -114,8 +114,6 @@ described here.
|
|||
Django version N+1. Pickles should not be used as part of a long-term
|
||||
archival strategy.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Since pickle compatibility errors can be difficult to diagnose, such as
|
||||
silently corrupted objects, a ``RuntimeWarning`` is raised when you try to
|
||||
unpickle a queryset in a Django version that is different than the one in
|
||||
|
@ -230,12 +228,6 @@ reference to a field on the model (or any related models), or an aggregate
|
|||
expression (averages, sums, etc) that has been computed over the objects that
|
||||
are related to the objects in the ``QuerySet``.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Previous versions of Django only allowed aggregate functions to be used as
|
||||
annotations. It is now possible to annotate a model with all kinds of
|
||||
expressions.
|
||||
|
||||
Each argument to ``annotate()`` is an annotation that will be added
|
||||
to each object in the ``QuerySet`` that is returned.
|
||||
|
||||
|
@ -334,10 +326,6 @@ calling ``asc()`` or ``desc()`` on the expression::
|
|||
|
||||
Entry.objects.order_by(Coalesce('summary', 'headline').desc())
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Ordering by query expressions was added.
|
||||
|
||||
Be cautious when ordering by fields in related models if you are also using
|
||||
:meth:`distinct()`. See the note in :meth:`distinct` for an explanation of how
|
||||
related model ordering can change the expected results.
|
||||
|
@ -381,10 +369,6 @@ ordering::
|
|||
|
||||
Entry.objects.order_by(Lower('headline').desc())
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ability to order by expressions like ``Lower`` was added.
|
||||
|
||||
If you don't want any ordering to be applied to a query, not even the default
|
||||
ordering, call :meth:`order_by()` with no parameters.
|
||||
|
||||
|
@ -1224,10 +1208,6 @@ of the arguments is required, but you should use at least one of them.
|
|||
If you need to use a literal ``%s`` inside your select string, use
|
||||
the sequence ``%%s``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Prior to 1.8, you were unable to escape a literal ``%s``.
|
||||
|
||||
* ``where`` / ``tables``
|
||||
|
||||
You can define explicit SQL ``WHERE`` clauses — perhaps to perform
|
||||
|
@ -2868,21 +2848,12 @@ All aggregates have the following parameters in common:
|
|||
A string that references a field on the model, or a :doc:`query expression
|
||||
</ref/models/expressions>`.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Aggregate functions are now able to reference multiple fields in complex
|
||||
computations.
|
||||
|
||||
``output_field``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
An optional argument that represents the :doc:`model field </ref/models/fields>`
|
||||
of the return value
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``output_field`` argument was added.
|
||||
|
||||
.. note::
|
||||
|
||||
When combining multiple field types, Django can only determine the
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue