mirror of
https://github.com/django/django.git
synced 2025-08-04 10:59:45 +00:00
Fixed many more ReST indentation errors, somehow accidentally missed from [16955]
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16983 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Luke Plant
parent
5109ac3709
commit
d1e5c55258
129 changed files with 5708 additions and 5740 deletions
|
|
@ -205,26 +205,26 @@ first manager declared is the *default manager*, it is important to allow that
|
|||
to be controlled. So here's how Django handles custom managers and
|
||||
:ref:`model inheritance <model-inheritance>`:
|
||||
|
||||
1. Managers defined on non-abstract base classes are *not* inherited by
|
||||
child classes. If you want to reuse a manager from a non-abstract base,
|
||||
redeclare it explicitly on the child class. These sorts of managers are
|
||||
likely to be fairly specific to the class they are defined on, so
|
||||
inheriting them can often lead to unexpected results (particularly as
|
||||
far as the default manager goes). Therefore, they aren't passed onto
|
||||
child classes.
|
||||
1. Managers defined on non-abstract base classes are *not* inherited by
|
||||
child classes. If you want to reuse a manager from a non-abstract base,
|
||||
redeclare it explicitly on the child class. These sorts of managers are
|
||||
likely to be fairly specific to the class they are defined on, so
|
||||
inheriting them can often lead to unexpected results (particularly as
|
||||
far as the default manager goes). Therefore, they aren't passed onto
|
||||
child classes.
|
||||
|
||||
2. Managers from abstract base classes are always inherited by the child
|
||||
class, using Python's normal name resolution order (names on the child
|
||||
class override all others; then come names on the first parent class,
|
||||
and so on). Abstract base classes are designed to capture information
|
||||
and behavior that is common to their child classes. Defining common
|
||||
managers is an appropriate part of this common information.
|
||||
2. Managers from abstract base classes are always inherited by the child
|
||||
class, using Python's normal name resolution order (names on the child
|
||||
class override all others; then come names on the first parent class,
|
||||
and so on). Abstract base classes are designed to capture information
|
||||
and behavior that is common to their child classes. Defining common
|
||||
managers is an appropriate part of this common information.
|
||||
|
||||
3. The default manager on a class is either the first manager declared on
|
||||
the class, if that exists, or the default manager of the first abstract
|
||||
base class in the parent hierarchy, if that exists. If no default
|
||||
manager is explicitly declared, Django's normal default manager is
|
||||
used.
|
||||
3. The default manager on a class is either the first manager declared on
|
||||
the class, if that exists, or the default manager of the first abstract
|
||||
base class in the parent hierarchy, if that exists. If no default
|
||||
manager is explicitly declared, Django's normal default manager is
|
||||
used.
|
||||
|
||||
These rules provide the necessary flexibility if you want to install a
|
||||
collection of custom managers on a group of models, via an abstract base
|
||||
|
|
|
|||
|
|
@ -10,13 +10,13 @@ model maps to a single database table.
|
|||
|
||||
The basics:
|
||||
|
||||
* Each model is a Python class that subclasses
|
||||
:class:`django.db.models.Model`.
|
||||
* Each model is a Python class that subclasses
|
||||
:class:`django.db.models.Model`.
|
||||
|
||||
* Each attribute of the model represents a database field.
|
||||
* Each attribute of the model represents a database field.
|
||||
|
||||
* With all of this, Django gives you an automatically-generated
|
||||
database-access API; see :doc:`/topics/db/queries`.
|
||||
* With all of this, Django gives you an automatically-generated
|
||||
database-access API; see :doc:`/topics/db/queries`.
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
|
@ -53,16 +53,16 @@ The above ``Person`` model would create a database table like this:
|
|||
|
||||
Some technical notes:
|
||||
|
||||
* The name of the table, ``myapp_person``, is automatically derived from
|
||||
some model metadata but can be overridden. See :ref:`table-names` for more
|
||||
details..
|
||||
* The name of the table, ``myapp_person``, is automatically derived from
|
||||
some model metadata but can be overridden. See :ref:`table-names` for more
|
||||
details..
|
||||
|
||||
* An ``id`` field is added automatically, but this behavior can be
|
||||
overridden. See :ref:`automatic-primary-key-fields`.
|
||||
* An ``id`` field is added automatically, but this behavior can be
|
||||
overridden. See :ref:`automatic-primary-key-fields`.
|
||||
|
||||
* The ``CREATE TABLE`` SQL in this example is formatted using PostgreSQL
|
||||
syntax, but it's worth noting Django uses SQL tailored to the database
|
||||
backend specified in your :doc:`settings file </topics/settings>`.
|
||||
* The ``CREATE TABLE`` SQL in this example is formatted using PostgreSQL
|
||||
syntax, but it's worth noting Django uses SQL tailored to the database
|
||||
backend specified in your :doc:`settings file </topics/settings>`.
|
||||
|
||||
Using models
|
||||
============
|
||||
|
|
@ -113,13 +113,13 @@ Each field in your model should be an instance of the appropriate
|
|||
:class:`~django.db.models.Field` class. Django uses the field class types to
|
||||
determine a few things:
|
||||
|
||||
* The database column type (e.g. ``INTEGER``, ``VARCHAR``).
|
||||
* The database column type (e.g. ``INTEGER``, ``VARCHAR``).
|
||||
|
||||
* The :doc:`widget </ref/forms/widgets>` to use in Django's admin interface,
|
||||
if you care to use it (e.g. ``<input type="text">``, ``<select>``).
|
||||
* The :doc:`widget </ref/forms/widgets>` to use in Django's admin interface,
|
||||
if you care to use it (e.g. ``<input type="text">``, ``<select>``).
|
||||
|
||||
* The minimal validation requirements, used in Django's admin and in
|
||||
automatically-generated forms.
|
||||
* The minimal validation requirements, used in Django's admin and in
|
||||
automatically-generated forms.
|
||||
|
||||
Django ships with dozens of built-in field types; you can find the complete list
|
||||
in the :ref:`model field reference <model-field-types>`. You can easily write
|
||||
|
|
@ -140,83 +140,83 @@ optional. They're fully explained in the :ref:`reference
|
|||
<common-model-field-options>`, but here's a quick summary of the most often-used
|
||||
ones:
|
||||
|
||||
:attr:`~Field.null`
|
||||
If ``True``, Django will store empty values as ``NULL`` in the database.
|
||||
Default is ``False``.
|
||||
:attr:`~Field.null`
|
||||
If ``True``, Django will store empty values as ``NULL`` in the database.
|
||||
Default is ``False``.
|
||||
|
||||
:attr:`~Field.blank`
|
||||
If ``True``, the field is allowed to be blank. Default is ``False``.
|
||||
:attr:`~Field.blank`
|
||||
If ``True``, the field is allowed to be blank. Default is ``False``.
|
||||
|
||||
Note that this is different than :attr:`~Field.null`.
|
||||
:attr:`~Field.null` is purely database-related, whereas
|
||||
:attr:`~Field.blank` is validation-related. If a field has
|
||||
:attr:`blank=True <Field.blank>`, validation on Django's admin site will
|
||||
allow entry of an empty value. If a field has :attr:`blank=False
|
||||
<Field.blank>`, the field will be required.
|
||||
Note that this is different than :attr:`~Field.null`.
|
||||
:attr:`~Field.null` is purely database-related, whereas
|
||||
:attr:`~Field.blank` is validation-related. If a field has
|
||||
:attr:`blank=True <Field.blank>`, validation on Django's admin site will
|
||||
allow entry of an empty value. If a field has :attr:`blank=False
|
||||
<Field.blank>`, the field will be required.
|
||||
|
||||
:attr:`~Field.choices`
|
||||
An iterable (e.g., a list or tuple) of 2-tuples to use as choices for
|
||||
this field. If this is given, Django's admin will use a select box
|
||||
instead of the standard text field and will limit choices to the choices
|
||||
given.
|
||||
:attr:`~Field.choices`
|
||||
An iterable (e.g., a list or tuple) of 2-tuples to use as choices for
|
||||
this field. If this is given, Django's admin will use a select box
|
||||
instead of the standard text field and will limit choices to the choices
|
||||
given.
|
||||
|
||||
A choices list looks like this::
|
||||
A choices list looks like this::
|
||||
|
||||
YEAR_IN_SCHOOL_CHOICES = (
|
||||
(u'FR', u'Freshman'),
|
||||
(u'SO', u'Sophomore'),
|
||||
(u'JR', u'Junior'),
|
||||
(u'SR', u'Senior'),
|
||||
(u'GR', u'Graduate'),
|
||||
YEAR_IN_SCHOOL_CHOICES = (
|
||||
(u'FR', u'Freshman'),
|
||||
(u'SO', u'Sophomore'),
|
||||
(u'JR', u'Junior'),
|
||||
(u'SR', u'Senior'),
|
||||
(u'GR', u'Graduate'),
|
||||
)
|
||||
|
||||
The first element in each tuple is the value that will be stored in the
|
||||
database, the second element will be displayed by the admin interface,
|
||||
or in a ModelChoiceField. Given an instance of a model object, the
|
||||
display value for a choices field can be accessed using the
|
||||
``get_FOO_display`` method. For example::
|
||||
|
||||
from django.db import models
|
||||
|
||||
class Person(models.Model):
|
||||
GENDER_CHOICES = (
|
||||
(u'M', u'Male'),
|
||||
(u'F', u'Female'),
|
||||
)
|
||||
name = models.CharField(max_length=60)
|
||||
gender = models.CharField(max_length=2, choices=GENDER_CHOICES)
|
||||
|
||||
The first element in each tuple is the value that will be stored in the
|
||||
database, the second element will be displayed by the admin interface,
|
||||
or in a ModelChoiceField. Given an instance of a model object, the
|
||||
display value for a choices field can be accessed using the
|
||||
``get_FOO_display`` method. For example::
|
||||
::
|
||||
|
||||
from django.db import models
|
||||
>>> p = Person(name="Fred Flintstone", gender="M")
|
||||
>>> p.save()
|
||||
>>> p.gender
|
||||
u'M'
|
||||
>>> p.get_gender_display()
|
||||
u'Male'
|
||||
|
||||
class Person(models.Model):
|
||||
GENDER_CHOICES = (
|
||||
(u'M', u'Male'),
|
||||
(u'F', u'Female'),
|
||||
)
|
||||
name = models.CharField(max_length=60)
|
||||
gender = models.CharField(max_length=2, choices=GENDER_CHOICES)
|
||||
:attr:`~Field.default`
|
||||
The default value for the field. This can be a value or a callable
|
||||
object. If callable it will be called every time a new object is
|
||||
created.
|
||||
|
||||
::
|
||||
:attr:`~Field.help_text`
|
||||
Extra "help" text to be displayed under the field on the object's admin
|
||||
form. It's useful for documentation even if your object doesn't have an
|
||||
admin form.
|
||||
|
||||
>>> p = Person(name="Fred Flintstone", gender="M")
|
||||
>>> p.save()
|
||||
>>> p.gender
|
||||
u'M'
|
||||
>>> p.get_gender_display()
|
||||
u'Male'
|
||||
:attr:`~Field.primary_key`
|
||||
If ``True``, this field is the primary key for the model.
|
||||
|
||||
:attr:`~Field.default`
|
||||
The default value for the field. This can be a value or a callable
|
||||
object. If callable it will be called every time a new object is
|
||||
created.
|
||||
If you don't specify :attr:`primary_key=True <Field.primary_key>` for
|
||||
any fields in your model, Django will automatically add an
|
||||
:class:`IntegerField` to hold the primary key, so you don't need to set
|
||||
:attr:`primary_key=True <Field.primary_key>` on any of your fields
|
||||
unless you want to override the default primary-key behavior. For more,
|
||||
see :ref:`automatic-primary-key-fields`.
|
||||
|
||||
:attr:`~Field.help_text`
|
||||
Extra "help" text to be displayed under the field on the object's admin
|
||||
form. It's useful for documentation even if your object doesn't have an
|
||||
admin form.
|
||||
|
||||
:attr:`~Field.primary_key`
|
||||
If ``True``, this field is the primary key for the model.
|
||||
|
||||
If you don't specify :attr:`primary_key=True <Field.primary_key>` for
|
||||
any fields in your model, Django will automatically add an
|
||||
:class:`IntegerField` to hold the primary key, so you don't need to set
|
||||
:attr:`primary_key=True <Field.primary_key>` on any of your fields
|
||||
unless you want to override the default primary-key behavior. For more,
|
||||
see :ref:`automatic-primary-key-fields`.
|
||||
|
||||
:attr:`~Field.unique`
|
||||
If ``True``, this field must be unique throughout the table.
|
||||
:attr:`~Field.unique`
|
||||
If ``True``, this field must be unique throughout the table.
|
||||
|
||||
Again, these are just short descriptions of the most common field options. Full
|
||||
details can be found in the :ref:`common model field option reference
|
||||
|
|
@ -435,24 +435,24 @@ explicit declaration defines how the two models are related.
|
|||
|
||||
There are a few restrictions on the intermediate model:
|
||||
|
||||
* Your intermediate model must contain one - and *only* one - foreign key
|
||||
to the target model (this would be ``Person`` in our example). If you
|
||||
have more than one foreign key, a validation error will be raised.
|
||||
* Your intermediate model must contain one - and *only* one - foreign key
|
||||
to the target model (this would be ``Person`` in our example). If you
|
||||
have more than one foreign key, a validation error will be raised.
|
||||
|
||||
* Your intermediate model must contain one - and *only* one - foreign key
|
||||
to the source model (this would be ``Group`` in our example). If you
|
||||
have more than one foreign key, a validation error will be raised.
|
||||
* Your intermediate model must contain one - and *only* one - foreign key
|
||||
to the source model (this would be ``Group`` in our example). If you
|
||||
have more than one foreign key, a validation error will be raised.
|
||||
|
||||
* The only exception to this is a model which has a many-to-many
|
||||
relationship to itself, through an intermediary model. In this
|
||||
case, two foreign keys to the same model are permitted, but they
|
||||
will be treated as the two (different) sides of the many-to-many
|
||||
relation.
|
||||
* The only exception to this is a model which has a many-to-many
|
||||
relationship to itself, through an intermediary model. In this
|
||||
case, two foreign keys to the same model are permitted, but they
|
||||
will be treated as the two (different) sides of the many-to-many
|
||||
relation.
|
||||
|
||||
* When defining a many-to-many relationship from a model to
|
||||
itself, using an intermediary model, you *must* use
|
||||
:attr:`symmetrical=False <ManyToManyField.symmetrical>` (see
|
||||
:ref:`the model field reference <manytomany-arguments>`).
|
||||
* When defining a many-to-many relationship from a model to
|
||||
itself, using an intermediary model, you *must* use
|
||||
:attr:`symmetrical=False <ManyToManyField.symmetrical>` (see
|
||||
:ref:`the model field reference <manytomany-arguments>`).
|
||||
|
||||
Now that you have set up your :class:`~django.db.models.ManyToManyField` to use
|
||||
your intermediary model (``Membership``, in this case), you're ready to start
|
||||
|
|
@ -601,17 +601,17 @@ Field name restrictions
|
|||
|
||||
Django places only two restrictions on model field names:
|
||||
|
||||
1. A field name cannot be a Python reserved word, because that would result
|
||||
in a Python syntax error. For example::
|
||||
1. A field name cannot be a Python reserved word, because that would result
|
||||
in a Python syntax error. For example::
|
||||
|
||||
class Example(models.Model):
|
||||
pass = models.IntegerField() # 'pass' is a reserved word!
|
||||
class Example(models.Model):
|
||||
pass = models.IntegerField() # 'pass' is a reserved word!
|
||||
|
||||
2. A field name cannot contain more than one underscore in a row, due to
|
||||
the way Django's query lookup syntax works. For example::
|
||||
2. A field name cannot contain more than one underscore in a row, due to
|
||||
the way Django's query lookup syntax works. For example::
|
||||
|
||||
class Example(models.Model):
|
||||
foo__bar = models.IntegerField() # 'foo__bar' has two underscores!
|
||||
class Example(models.Model):
|
||||
foo__bar = models.IntegerField() # 'foo__bar' has two underscores!
|
||||
|
||||
These limitations can be worked around, though, because your field name doesn't
|
||||
necessarily have to match your database column name. See the
|
||||
|
|
@ -702,23 +702,23 @@ of :ref:`methods automatically given to each model <model-instance-methods>`.
|
|||
You can override most of these -- see `overriding predefined model methods`_,
|
||||
below -- but there are a couple that you'll almost always want to define:
|
||||
|
||||
:meth:`~Model.__unicode__`
|
||||
A Python "magic method" that returns a unicode "representation" of any
|
||||
object. This is what Python and Django will use whenever a model
|
||||
instance needs to be coerced and displayed as a plain string. Most
|
||||
notably, this happens when you display an object in an interactive
|
||||
console or in the admin.
|
||||
:meth:`~Model.__unicode__`
|
||||
A Python "magic method" that returns a unicode "representation" of any
|
||||
object. This is what Python and Django will use whenever a model
|
||||
instance needs to be coerced and displayed as a plain string. Most
|
||||
notably, this happens when you display an object in an interactive
|
||||
console or in the admin.
|
||||
|
||||
You'll always want to define this method; the default isn't very helpful
|
||||
at all.
|
||||
You'll always want to define this method; the default isn't very helpful
|
||||
at all.
|
||||
|
||||
:meth:`~Model.get_absolute_url`
|
||||
This tells Django how to calculate the URL for an object. Django uses
|
||||
this in its admin interface, and any time it needs to figure out a URL
|
||||
for an object.
|
||||
:meth:`~Model.get_absolute_url`
|
||||
This tells Django how to calculate the URL for an object. Django uses
|
||||
this in its admin interface, and any time it needs to figure out a URL
|
||||
for an object.
|
||||
|
||||
Any object that has a URL that uniquely identifies it should define this
|
||||
method.
|
||||
Any object that has a URL that uniquely identifies it should define this
|
||||
method.
|
||||
|
||||
.. _overriding-model-methods:
|
||||
|
||||
|
|
@ -800,16 +800,16 @@ models.
|
|||
|
||||
There are three styles of inheritance that are possible in Django.
|
||||
|
||||
1. Often, you will just want to use the parent class to hold information that
|
||||
you don't want to have to type out for each child model. This class isn't
|
||||
going to ever be used in isolation, so :ref:`abstract-base-classes` are
|
||||
what you're after.
|
||||
2. If you're subclassing an existing model (perhaps something from another
|
||||
application entirely) and want each model to have its own database table,
|
||||
:ref:`multi-table-inheritance` is the way to go.
|
||||
3. Finally, if you only want to modify the Python-level behavior of a model,
|
||||
without changing the models fields in any way, you can use
|
||||
:ref:`proxy-models`.
|
||||
1. Often, you will just want to use the parent class to hold information that
|
||||
you don't want to have to type out for each child model. This class isn't
|
||||
going to ever be used in isolation, so :ref:`abstract-base-classes` are
|
||||
what you're after.
|
||||
2. If you're subclassing an existing model (perhaps something from another
|
||||
application entirely) and want each model to have its own database table,
|
||||
:ref:`multi-table-inheritance` is the way to go.
|
||||
3. Finally, if you only want to modify the Python-level behavior of a model,
|
||||
without changing the models fields in any way, you can use
|
||||
:ref:`proxy-models`.
|
||||
|
||||
.. _abstract-base-classes:
|
||||
|
||||
|
|
@ -1197,14 +1197,14 @@ were needed in any case, so the current separation arose.
|
|||
|
||||
So, the general rules are:
|
||||
|
||||
1. If you are mirroring an existing model or database table and don't want
|
||||
all the original database table columns, use ``Meta.managed=False``.
|
||||
That option is normally useful for modeling database views and tables
|
||||
not under the control of Django.
|
||||
2. If you are wanting to change the Python-only behavior of a model, but
|
||||
keep all the same fields as in the original, use ``Meta.proxy=True``.
|
||||
This sets things up so that the proxy model is an exact copy of the
|
||||
storage structure of the original model when data is saved.
|
||||
1. If you are mirroring an existing model or database table and don't want
|
||||
all the original database table columns, use ``Meta.managed=False``.
|
||||
That option is normally useful for modeling database views and tables
|
||||
not under the control of Django.
|
||||
2. If you are wanting to change the Python-only behavior of a model, but
|
||||
keep all the same fields as in the original, use ``Meta.proxy=True``.
|
||||
This sets things up so that the proxy model is an exact copy of the
|
||||
storage structure of the original model when data is saved.
|
||||
|
||||
Multiple inheritance
|
||||
--------------------
|
||||
|
|
|
|||
|
|
@ -224,21 +224,21 @@ many-to-many relation to User, the following template code is optimal:
|
|||
|
||||
It is optimal because:
|
||||
|
||||
1. Since QuerySets are lazy, this does no database queries if 'display_inbox'
|
||||
is False.
|
||||
1. Since QuerySets are lazy, this does no database queries if 'display_inbox'
|
||||
is False.
|
||||
|
||||
#. Use of :ttag:`with` means that we store ``user.emails.all`` in a variable
|
||||
for later use, allowing its cache to be re-used.
|
||||
#. Use of :ttag:`with` means that we store ``user.emails.all`` in a variable
|
||||
for later use, allowing its cache to be re-used.
|
||||
|
||||
#. The line ``{% if emails %}`` causes ``QuerySet.__nonzero__()`` to be called,
|
||||
which causes the ``user.emails.all()`` query to be run on the database, and
|
||||
at the least the first line to be turned into an ORM object. If there aren't
|
||||
any results, it will return False, otherwise True.
|
||||
#. The line ``{% if emails %}`` causes ``QuerySet.__nonzero__()`` to be called,
|
||||
which causes the ``user.emails.all()`` query to be run on the database, and
|
||||
at the least the first line to be turned into an ORM object. If there aren't
|
||||
any results, it will return False, otherwise True.
|
||||
|
||||
#. The use of ``{{ emails|length }}`` calls ``QuerySet.__len__()``, filling
|
||||
out the rest of the cache without doing another query.
|
||||
#. The use of ``{{ emails|length }}`` calls ``QuerySet.__len__()``, filling
|
||||
out the rest of the cache without doing another query.
|
||||
|
||||
#. The :ttag:`for` loop iterates over the already filled cache.
|
||||
#. The :ttag:`for` loop iterates over the already filled cache.
|
||||
|
||||
In total, this code does either one or zero database queries. The only
|
||||
deliberate optimization performed is the use of the :ttag:`with` tag. Using
|
||||
|
|
|
|||
|
|
@ -184,13 +184,13 @@ complete set of objects.
|
|||
To create such a subset, you refine the initial ``QuerySet``, adding filter
|
||||
conditions. The two most common ways to refine a ``QuerySet`` are:
|
||||
|
||||
``filter(**kwargs)``
|
||||
Returns a new ``QuerySet`` containing objects that match the given
|
||||
lookup parameters.
|
||||
``filter(**kwargs)``
|
||||
Returns a new ``QuerySet`` containing objects that match the given
|
||||
lookup parameters.
|
||||
|
||||
``exclude(**kwargs)``
|
||||
Returns a new ``QuerySet`` containing objects that do *not* match the
|
||||
given lookup parameters.
|
||||
``exclude(**kwargs)``
|
||||
Returns a new ``QuerySet`` containing objects that do *not* match the
|
||||
given lookup parameters.
|
||||
|
||||
The lookup parameters (``**kwargs`` in the above function definitions) should
|
||||
be in the format described in `Field lookups`_ below.
|
||||
|
|
@ -391,56 +391,56 @@ The database API supports about two dozen lookup types; a complete reference
|
|||
can be found in the :ref:`field lookup reference <field-lookups>`. To give you a taste of what's available, here's some of the more common lookups
|
||||
you'll probably use:
|
||||
|
||||
:lookup:`exact`
|
||||
An "exact" match. For example::
|
||||
:lookup:`exact`
|
||||
An "exact" match. For example::
|
||||
|
||||
>>> Entry.objects.get(headline__exact="Man bites dog")
|
||||
>>> Entry.objects.get(headline__exact="Man bites dog")
|
||||
|
||||
Would generate SQL along these lines:
|
||||
Would generate SQL along these lines:
|
||||
|
||||
.. code-block:: sql
|
||||
.. code-block:: sql
|
||||
|
||||
SELECT ... WHERE headline = 'Man bites dog';
|
||||
SELECT ... WHERE headline = 'Man bites dog';
|
||||
|
||||
If you don't provide a lookup type -- that is, if your keyword argument
|
||||
doesn't contain a double underscore -- the lookup type is assumed to be
|
||||
``exact``.
|
||||
If you don't provide a lookup type -- that is, if your keyword argument
|
||||
doesn't contain a double underscore -- the lookup type is assumed to be
|
||||
``exact``.
|
||||
|
||||
For example, the following two statements are equivalent::
|
||||
For example, the following two statements are equivalent::
|
||||
|
||||
>>> Blog.objects.get(id__exact=14) # Explicit form
|
||||
>>> Blog.objects.get(id=14) # __exact is implied
|
||||
>>> Blog.objects.get(id__exact=14) # Explicit form
|
||||
>>> Blog.objects.get(id=14) # __exact is implied
|
||||
|
||||
This is for convenience, because ``exact`` lookups are the common case.
|
||||
This is for convenience, because ``exact`` lookups are the common case.
|
||||
|
||||
:lookup:`iexact`
|
||||
A case-insensitive match. So, the query::
|
||||
:lookup:`iexact`
|
||||
A case-insensitive match. So, the query::
|
||||
|
||||
>>> Blog.objects.get(name__iexact="beatles blog")
|
||||
>>> Blog.objects.get(name__iexact="beatles blog")
|
||||
|
||||
Would match a ``Blog`` titled "Beatles Blog", "beatles blog", or even
|
||||
"BeAtlES blOG".
|
||||
Would match a ``Blog`` titled "Beatles Blog", "beatles blog", or even
|
||||
"BeAtlES blOG".
|
||||
|
||||
:lookup:`contains`
|
||||
Case-sensitive containment test. For example::
|
||||
:lookup:`contains`
|
||||
Case-sensitive containment test. For example::
|
||||
|
||||
Entry.objects.get(headline__contains='Lennon')
|
||||
Entry.objects.get(headline__contains='Lennon')
|
||||
|
||||
Roughly translates to this SQL:
|
||||
Roughly translates to this SQL:
|
||||
|
||||
.. code-block:: sql
|
||||
.. code-block:: sql
|
||||
|
||||
SELECT ... WHERE headline LIKE '%Lennon%';
|
||||
SELECT ... WHERE headline LIKE '%Lennon%';
|
||||
|
||||
Note this will match the headline ``'Today Lennon honored'`` but not
|
||||
``'today lennon honored'``.
|
||||
Note this will match the headline ``'Today Lennon honored'`` but not
|
||||
``'today lennon honored'``.
|
||||
|
||||
There's also a case-insensitive version, :lookup:`icontains`.
|
||||
There's also a case-insensitive version, :lookup:`icontains`.
|
||||
|
||||
:lookup:`startswith`, :lookup:`endswith`
|
||||
Starts-with and ends-with search, respectively. There are also
|
||||
case-insensitive versions called :lookup:`istartswith` and
|
||||
:lookup:`iendswith`.
|
||||
:lookup:`startswith`, :lookup:`endswith`
|
||||
Starts-with and ends-with search, respectively. There are also
|
||||
case-insensitive versions called :lookup:`istartswith` and
|
||||
:lookup:`iendswith`.
|
||||
|
||||
Again, this only scratches the surface. A complete reference can be found in the
|
||||
:ref:`field lookup reference <field-lookups>`.
|
||||
|
|
|
|||
|
|
@ -69,29 +69,29 @@ per-function or per-code-block basis.
|
|||
|
||||
These functions, described in detail below, can be used in two different ways:
|
||||
|
||||
* As a decorator_ on a particular function. For example::
|
||||
* As a decorator_ on a particular function. For example::
|
||||
|
||||
from django.db import transaction
|
||||
from django.db import transaction
|
||||
|
||||
@transaction.commit_on_success
|
||||
def viewfunc(request):
|
||||
# ...
|
||||
# this code executes inside a transaction
|
||||
# ...
|
||||
@transaction.commit_on_success
|
||||
def viewfunc(request):
|
||||
# ...
|
||||
# this code executes inside a transaction
|
||||
# ...
|
||||
|
||||
* As a `context manager`_ around a particular block of code::
|
||||
* As a `context manager`_ around a particular block of code::
|
||||
|
||||
from django.db import transaction
|
||||
from django.db import transaction
|
||||
|
||||
def viewfunc(request):
|
||||
# ...
|
||||
# this code executes using default transaction management
|
||||
# ...
|
||||
def viewfunc(request):
|
||||
# ...
|
||||
# this code executes using default transaction management
|
||||
# ...
|
||||
|
||||
with transaction.commit_on_success():
|
||||
# ...
|
||||
# this code executes inside a transaction
|
||||
# ...
|
||||
with transaction.commit_on_success():
|
||||
# ...
|
||||
# this code executes inside a transaction
|
||||
# ...
|
||||
|
||||
Both techniques work with all supported version of Python. However, in Python
|
||||
2.5, you must add ``from __future__ import with_statement`` at the beginning
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue