1
0
mirror of https://github.com/django/django.git synced 2025-07-04 09:49:12 +00:00

magic-removal: Reorganised and did initial revisions to db-api documentation. Still has many sections that require fleshing out.

git-svn-id: http://code.djangoproject.com/svn/django/branches/magic-removal@2679 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Russell Keith-Magee 2006-04-12 00:28:07 +00:00
parent 24541dcb73
commit 4b3272fae8

View File

@ -10,72 +10,150 @@ models, and how to create, retrieve and update objects.
Throughout this reference, we'll refer to the following Poll application:: Throughout this reference, we'll refer to the following Poll application::
class Poll(meta.Model): class Poll(models.Model):
slug = meta.SlugField(unique_for_month='pub_date') slug = models.SlugField(unique_for_month='pub_date')
question = meta.CharField(maxlength=255) question = models.CharField(maxlength=255)
pub_date = meta.DateTimeField() pub_date = models.DateTimeField()
expire_date = meta.DateTimeField() expire_date = models.DateTimeField()
def __repr__(self): def __repr__(self):
return self.question return self.question
class Choice(meta.Model): class Choice(models.Model):
poll = meta.ForeignKey(Poll, edit_inline=meta.TABULAR, poll = models.ForeignKey(Poll, edit_inline=meta.TABULAR,
num_in_admin=10, min_num_in_admin=5) num_in_admin=10, min_num_in_admin=5)
choice = meta.CharField(maxlength=255, core=True) choice = models.CharField(maxlength=255, core=True)
votes = meta.IntegerField(editable=False, default=0) votes = models.IntegerField(editable=False, default=0)
def __repr__(self): def __repr__(self):
return self.choice return self.choice
Basic lookup functions How Queries Work
====================== ================
Each model exposes these module-level functions for lookups: Querying in Django is based upon the construction and evaluation of Query Sets.
get_object(\**kwargs) A Query Set is a representation of a query.
---------------------
When you compose a query using Django, you construct a Query Set; when you want
to evaluate the query, you iterate over or slice the Query Set that represents
your query.
Every Django model has a Manager object that acts as a factory for new query sets.
The manager has a special factory method for creating Suery Sets::
queryset = Poll.objects.all()
This creates a new Query Set that matches all the objects of the given class.
Query Set evaluation
====================
Once you have constructed a Query Set to meet your needs
A Query Set is an iterable object::
queryset = Poll.objects.all()
for p in queryset:
print p
Query Sets can also be sliced::
fifth_poll = queryset[4]
all_polls_but_the_first_two = queryset[2:]
Regardless of the method used to extract data from the Query Set, upon first
evaluation, the query will be executed on the database, and the results cached.
Subsequent evaluations on the database will reuse the cached results.
As an alternative to iteration and slicing, you can use one of the
following functions. These functions do not populate or effect the cache:
get(\**kwargs)
--------------
Returns the object matching the given lookup parameters, which should be in Returns the object matching the given lookup parameters, which should be in
the format described in "Field lookups" below. Raises a module-level the format described in "Field lookups" below. Raises a module-level
``*DoesNotExist`` exception if an object wasn't found for the given parameters. ``DoesNotExist`` exception if an object wasn't found for the given parameters.
Raises ``AssertionError`` if more than one object was found. Raises ``AssertionError`` if more than one object was found.
get_list(\**kwargs) count()
------------------- -------
Returns a list of objects matching the given lookup parameters, which should be
in the format described in "Field lookups" below. If no objects match the given
parameters, it returns an empty list. ``get_list()`` will always return a list.
get_iterator(\**kwargs)
-----------------------
Just like ``get_list()``, except it returns an iterator instead of a list. This
is more efficient for large result sets. This example shows the difference::
# get_list() loads all objects into memory.
for obj in foos.get_list():
print repr(obj)
# get_iterator() only loads a number of objects into memory at a time.
for obj in foos.get_iterator():
print repr(obj)
get_count(\**kwargs)
--------------------
Returns an integer representing the number of objects in the database matching Returns an integer representing the number of objects in the database matching
the given lookup parameters, which should be in the format described in the Query Set. ``count()`` never raises exceptions
"Field lookups" below. ``get_count()`` never raises exceptions
Depending on which database you're using (e.g. PostgreSQL vs. MySQL), this may Depending on which database you're using (e.g. PostgreSQL vs. MySQL), this may
return a long integer instead of a normal Python integer. return a long integer instead of a normal Python integer.
get_values(\**kwargs) in_bulk(id_list)
----------------
Takes a list of IDs and returns a dictionary mapping each ID to an instance of
the object with the given ID. Also takes optional keyword lookup arguments,
which should be in the format described in "Field lookups" below. Here's an
example, using the ``Poll`` model defined above::
>>> from datetime import datetime
>>> p1 = Poll(slug='whatsup', question="What's up?",
... pub_date=datetime(2005, 2, 20), expire_date=datetime(2005, 3, 20))
>>> p1.save()
>>> p2 = Poll(slug='name', question="What's your name?",
... pub_date=datetime(2005, 3, 20), expire_date=datetime(2005, 4, 20))
>>> p2.save()
>>> Poll.objects.all()
[What's up?, What's your name?]
>>> Poll.objects.in_bulk([1])
{1: What's up?}
>>> Poll.objects.in_bulk([1, 2])
{1: What's up?, 2: What's your name?}
>>> Poll.objects.in_bulk([])
{}
latest(field_name=None)
-----------------------
Returns the latest object, according to the model's 'get_latest_by'
option or optional given field_name.
delete()
--------
Delete the members of the query set.
Query Set construction
======================
Any Query Set (evaluated or not) can be refined by calling one of the following methods:
filter(\**kwargs)
-------------------
Returns a new Query Set containing objects that match the given lookup parameters.
Lookup parameters should be in the format described in "Field lookups" below.
``filter()`` will always return a list.
exclude(\**kwargs)
-------------------
As for filter, but negated.
distinct()
----------
If ``distinct`` is True, only distinct rows will be returned. This is equivalent
to a ``SELECT DISTINCT`` SQL clause. You can use this with ``get_values()`` to
get distinct values. For example, this returns the distinct first_names::
>>> people.get_values(fields=['first_name'], distinct=True)
[{'first_name': 'Adrian'}, {'first_name': 'Jacob'}, {'first_name': 'Simon'}]
values(\*fields)
--------------------- ---------------------
Just like ``get_list()``, except it returns a list of dictionaries instead of Just like ``filter()``, except it returns a list of dictionaries instead of
model-instance objects. model-instance objects.
It accepts an optional parameter, ``fields``, which should be a list or tuple It accepts an optional parameter, ``fields``, which should be a list or tuple
@ -86,51 +164,75 @@ field keys/values for the fields you specify. Here's an example, using the
``Poll`` model defined above:: ``Poll`` model defined above::
>>> from datetime import datetime >>> from datetime import datetime
>>> p1 = polls.Poll(slug='whatsup', question="What's up?", >>> p1 = Poll(slug='whatsup', question="What's up?",
... pub_date=datetime(2005, 2, 20), expire_date=datetime(2005, 3, 20)) ... pub_date=datetime(2005, 2, 20), expire_date=datetime(2005, 3, 20))
>>> p1.save() >>> p1.save()
>>> p2 = polls.Poll(slug='name', question="What's your name?", >>> p2 = Poll(slug='name', question="What's your name?",
... pub_date=datetime(2005, 3, 20), expire_date=datetime(2005, 4, 20)) ... pub_date=datetime(2005, 3, 20), expire_date=datetime(2005, 4, 20))
>>> p2.save() >>> p2.save()
>>> polls.get_list() >>> Poll.objects.all()
[What's up?, What's your name?] [What's up?, What's your name?]
>>> polls.get_values() >>> Poll.objects.get_values()
[{'id': 1, 'slug': 'whatsup', 'question': "What's up?", 'pub_date': datetime.datetime(2005, 2, 20), 'expire_date': datetime.datetime(2005, 3, 20)}, [{'id': 1, 'slug': 'whatsup', 'question': "What's up?", 'pub_date': datetime.datetime(2005, 2, 20), 'expire_date': datetime.datetime(2005, 3, 20)},
{'id': 2, 'slug': 'name', 'question': "What's your name?", 'pub_date': datetime.datetime(2005, 3, 20), 'expire_date': datetime.datetime(2005, 4, 20)}] {'id': 2, 'slug': 'name', 'question': "What's your name?", 'pub_date': datetime.datetime(2005, 3, 20), 'expire_date': datetime.datetime(2005, 4, 20)}]
>>> polls.get_values(fields=['id', 'slug']) >>> Poll.objects.get_values(fields=['id', 'slug'])
[{'id': 1, 'slug': 'whatsup'}, {'id': 2, 'slug': 'name'}] [{'id': 1, 'slug': 'whatsup'}, {'id': 2, 'slug': 'name'}]
Use ``get_values()`` when you know you're only going to need a couple of field Use ``get_values()`` when you know you're only going to need a couple of field
values and you won't need the functionality of a model instance object. It's values and you won't need the functionality of a model instance object. It's
more efficient to select only the fields you need to use. more efficient to select only the fields you need to use.
get_values_iterator(\**kwargs) dates(field, kind, order='ASC')
------------------------------
Just like ``get_values()``, except it returns an iterator instead of a list.
See the section on ``get_iterator()`` above.
get_in_bulk(id_list, \**kwargs)
------------------------------- -------------------------------
Takes a list of IDs and returns a dictionary mapping each ID to an instance of Every manager has a ``dates()`` method, which returns a list of
the object with the given ID. Also takes optional keyword lookup arguments, ``datetime.datetime`` objects representing all available dates with the given
which should be in the format described in "Field lookups" below. Here's an filters (if any) and of the given scope, as defined by the ``kind`` argument.
example, using the ``Poll`` model defined above::
``field`` should be the name of a ``DateField`` or ``DateTimeField`` of your
model.
``kind`` should be either ``"year"``, ``"month"`` or ``"day"``. Each
``datetime.datetime`` object in the result list is "truncated" to the given
``type``.
* ``"year"`` returns a list of all distinct year values for the field.
* ``"month"`` returns a list of all distinct year/month values for the field.
* ``"day"`` returns a list of all distinct year/month/day values for the field.
``order``, which defaults to ``'ASC'``, should be either ``"ASC"`` or ``"DESC"``.
This specifies how to order the results.
Here's an example, using the ``Poll`` model defined above::
>>> from datetime import datetime >>> from datetime import datetime
>>> p1 = polls.Poll(slug='whatsup', question="What's up?", >>> p1 = Poll(slug='whatsup', question="What's up?",
... pub_date=datetime(2005, 2, 20), expire_date=datetime(2005, 3, 20)) ... pub_date=datetime(2005, 2, 20), expire_date=datetime(2005, 3, 20))
>>> p1.save() >>> p1.save()
>>> p2 = polls.Poll(slug='name', question="What's your name?", >>> p2 = Poll(slug='name', question="What's your name?",
... pub_date=datetime(2005, 3, 20), expire_date=datetime(2005, 4, 20)) ... pub_date=datetime(2005, 3, 20), expire_date=datetime(2005, 4, 20))
>>> p2.save() >>> p2.save()
>>> polls.get_list() >>> Poll.objects.dates('pub_date', 'year')
[What's up?, What's your name?] [datetime.datetime(2005, 1, 1)]
>>> polls.get_in_bulk([1]) >>> Poll.objects.dates('pub_date', 'month')
{1: What's up?} [datetime.datetime(2005, 2, 1), datetime.datetime(2005, 3, 1)]
>>> polls.get_in_bulk([1, 2]) >>> Poll.objects.dates('pub_date', 'day')
{1: What's up?, 2: What's your name?} [datetime.datetime(2005, 2, 20), datetime.datetime(2005, 3, 20)]
>>> Poll.objects.dates('pub_date', 'day', order='DESC')
[datetime.datetime(2005, 3, 20), datetime.datetime(2005, 2, 20)]
>>> Poll.objects.filter(question__contains='name').dates('pub_date', 'day')
[datetime.datetime(2005, 3, 20)]
Manager Shortcuts
=================
As a convenient shortcut, all of these Query Set functions (with the
exception of delete) can be accessed from the Manager object itself.
The following queries are identical::
Poll.objects.all().filter(question__startswith="What")
Poll.objects.filter(question__startswith="What")
Field lookups Field lookups
============= =============
@ -138,11 +240,11 @@ Field lookups
Basic field lookups take the form ``field__lookuptype`` (that's a Basic field lookups take the form ``field__lookuptype`` (that's a
double-underscore). For example:: double-underscore). For example::
polls.get_list(pub_date__lte=datetime.datetime.now()) Poll.objects.filter(pub_date__lte=datetime.datetime.now())
translates (roughly) into the following SQL:: translates (roughly) into the following SQL::
SELECT * FROM polls_polls WHERE pub_date <= NOW(); SELECT * FROM polls_poll WHERE pub_date <= NOW();
.. admonition:: How this is possible .. admonition:: How this is possible
@ -155,25 +257,25 @@ The DB API supports the following lookup types:
=========== ============================================================== =========== ==============================================================
Type Description Type Description
=========== ============================================================== =========== ==============================================================
exact Exact match: ``polls.get_object(id__exact=14)``. exact Exact match: ``Poll.objects.get(id__exact=14)`` returns all
polls with an ID of exactly 14.
iexact Case-insensitive exact match: iexact Case-insensitive exact match:
``polls.get_list(slug__iexact="foo")`` matches a slug of ``Poll.objects.filter(slug__iexact="foo")`` matches a slug of
``foo``, ``FOO``, ``fOo``, etc. ``foo``, ``FOO``, ``fOo``, etc.
contains Case-sensitive containment test: contains Case-sensitive containment test:
``polls.get_list(question__contains="spam")`` returns all polls ``Poll.objects.filter(question__contains="spam")`` returns all polls
that contain "spam" in the question. (PostgreSQL and MySQL that contain "spam" in the question. (PostgreSQL and MySQL
only. SQLite doesn't support case-sensitive LIKE statements; only. SQLite doesn't support case-sensitive LIKE statements;
``contains`` will act like ``icontains`` for SQLite.) ``contains`` will act like ``icontains`` for SQLite.)
icontains Case-insensitive containment test. icontains Case-insensitive containment test.
gt Greater than: ``polls.get_list(id__gt=4)``. gt Greater than: ``Poll.objects.filter(id__gt=4)``.
gte Greater than or equal to. gte Greater than or equal to.
lt Less than. lt Less than.
lte Less than or equal to. lte Less than or equal to.
ne Not equal to. in In a given list: ``Poll.objects.filter(id__in=[1, 3, 4])`` returns
in In a given list: ``polls.get_list(id__in=[1, 3, 4])`` returns
a list of polls whose IDs are either 1, 3 or 4. a list of polls whose IDs are either 1, 3 or 4.
startswith Case-sensitive starts-with: startswith Case-sensitive starts-with:
``polls.get_list(question__startswith="Would")``. (PostgreSQL ``Poll.objects.filter(question__startswith="Would")``. (PostgreSQL
and MySQL only. SQLite doesn't support case-sensitive LIKE and MySQL only. SQLite doesn't support case-sensitive LIKE
statements; ``startswith`` will act like ``istartswith`` for statements; ``startswith`` will act like ``istartswith`` for
SQLite.) SQLite.)
@ -181,39 +283,47 @@ The DB API supports the following lookup types:
istartswith Case-insensitive starts-with. istartswith Case-insensitive starts-with.
iendswith Case-insensitive ends-with. iendswith Case-insensitive ends-with.
range Range test: range Range test:
``polls.get_list(pub_date__range=(start_date, end_date))`` ``Poll.objects.filter(pub_date__range=(start_date, end_date))``
returns all polls with a pub_date between ``start_date`` returns all polls with a pub_date between ``start_date``
and ``end_date`` (inclusive). and ``end_date`` (inclusive).
year For date/datetime fields, exact year match: year For date/datetime fields, exact year match:
``polls.get_count(pub_date__year=2005)``. ``Poll.objects.count(pub_date__year=2005)``.
month For date/datetime fields, exact month match. month For date/datetime fields, exact month match.
day For date/datetime fields, exact day match. day For date/datetime fields, exact day match.
isnull True/False; does is IF NULL/IF NOT NULL lookup: isnull True/False; does is IF NULL/IF NOT NULL lookup:
``polls.get_list(expire_date__isnull=True)``. ``Poll.objects.filter(expire_date__isnull=True)``.
=========== ============================================================== =========== ==============================================================
Multiple lookups are allowed, of course, and are translated as "AND"s:: If no lookup type is provided, a type of ``exact`` is assumed. The following
two statements are equivalent::
polls.get_list( Poll.objects.get(id=14)
Poll.objects.get(id__exact=14)
Multiple lookups are also allowed. When separated by commans, the list of lookups will be
"AND"ed together::
Poll.objects.filter(
pub_date__year=2005, pub_date__year=2005,
pub_date__month=1, pub_date__month=1,
question__startswith="Would", question__startswith="Would",
) )
...retrieves all polls published in January 2005 that have a question starting with "Would." ...retrieves all polls published in January 2005 that have a question starting
with "Would."
For convenience, there's a ``pk`` lookup type, which translates into For convenience, there's a ``pk`` lookup type, which translates into
``(primary_key)__exact``. In the polls example, these two statements are ``(primary_key)``. In the polls example, these two statements are
equivalent:: equivalent::
polls.get_object(id__exact=3) Poll.objects.get(id__exact=3)
polls.get_object(pk=3) Poll.objects.get(pk=3)
``pk`` lookups also work across joins. In the polls example, these two ``pk`` lookups also work across joins. In the polls example, these two
statements are equivalent:: statements are equivalent::
choices.get_list(poll__id__exact=3) Choice.objects.filter(poll__id=3)
choices.get_list(poll__pk=3) Choice.objects.filter(poll__pk=3)
If you pass an invalid keyword argument, the function will raise ``TypeError``. If you pass an invalid keyword argument, the function will raise ``TypeError``.
@ -222,17 +332,19 @@ If you pass an invalid keyword argument, the function will raise ``TypeError``.
OR lookups OR lookups
---------- ----------
By default, keyword argument queries are "AND"ed together. If you have more complex query By default, keyword argument queries are "AND"ed together. If you have more
requirements (for example, you need to include an ``OR`` statement in your query), you need complex query requirements (for example, you need to include an ``OR``
to use ``Q`` objects. statement in your query), you need to use ``Q`` objects.
A ``Q`` object is an instance of ``django.core.meta.Q``, used to encapsulate a collection of A ``Q`` object (``django.db.models.Q``) is an object used to encapsulate a
keyword arguments. These keyword arguments are specified in the same way as keyword arguments to collection of keyword arguments. These keyword arguments are specified in
the basic lookup functions like get_object() and get_list(). For example:: the same way as keyword arguments to the basic lookup functions like get()
and filter(). For example::
Q(question__startswith='What') Q(question__startswith='What')
``Q`` objects can be combined using the ``&`` and ``|`` operators. When an operator is used on two is a ``Q`` object encapsulating a single ``LIKE`` query. ``Q`` objects can be
combined using the ``&`` and ``|`` operators. When an operator is used on two
``Q`` objects, it yields a new ``Q`` object. For example the statement:: ``Q`` objects, it yields a new ``Q`` object. For example the statement::
Q(question__startswith='Who') | Q(question__startswith='What') Q(question__startswith='Who') | Q(question__startswith='What')
@ -247,9 +359,9 @@ One or more ``Q`` objects can then provided as arguments to the lookup functions
``Q`` object arguments are provided to a lookup function, they will be "AND"ed together. ``Q`` object arguments are provided to a lookup function, they will be "AND"ed together.
For example:: For example::
polls.get_object( Poll.objects.get(
Q(question__startswith='Who'), Q(question__startswith='Who'),
Q(pub_date__exact=date(2005, 5, 2)) | Q(pub_date__exact=date(2005, 5, 6)) Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6))
) )
... roughly translates into the SQL:: ... roughly translates into the SQL::
@ -262,25 +374,25 @@ provided to a lookup function (be they keyword argument or ``Q`` object) are "AN
However, if a ``Q`` object is provided, it must precede the definition of any keyword arguments. However, if a ``Q`` object is provided, it must precede the definition of any keyword arguments.
For example:: For example::
polls.get_object( Poll.objects.get(
Q(pub_date__exact=date(2005, 5, 2)) | Q(pub_date__exact=date(2005, 5, 6)), Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6)),
question__startswith='Who') question__startswith='Who')
... would be a valid query, equivalent to the previous example; but:: ... would be a valid query, equivalent to the previous example; but::
# INVALID QUERY # INVALID QUERY
polls.get_object( Poll.objects.get(
question__startswith='Who', question__startswith='Who',
Q(pub_date__exact=date(2005, 5, 2)) | Q(pub_date__exact=date(2005, 5, 6))) Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6)))
... would not be valid. ... would not be valid.
A ``Q`` objects can also be provided to the ``complex`` keyword argument. For example:: A ``Q`` objects can also be provided to the ``complex`` keyword argument. For example::
polls.get_object( Poll.objects.get(
complex=Q(question__startswith='Who') & complex=Q(question__startswith='Who') &
(Q(pub_date__exact=date(2005, 5, 2)) | (Q(pub_date=date(2005, 5, 2)) |
Q(pub_date__exact=date(2005, 5, 6)) Q(pub_date=date(2005, 5, 6))
) )
) )
@ -295,23 +407,20 @@ The results are automatically ordered by the ordering tuple given by the
``ordering`` key in the model, but the ordering may be explicitly ``ordering`` key in the model, but the ordering may be explicitly
provided by the ``order_by`` argument to a lookup:: provided by the ``order_by`` argument to a lookup::
polls.get_list( Poll.objects.filter(pub_date__year=2005,
pub_date__year=2005, pub_date__month=1).order_by('-pub_date', 'question')
pub_date__month=1,
order_by=('-pub_date', 'question'),
)
The result set above will be ordered by ``pub_date`` descending, then The result set above will be ordered by ``pub_date`` descending, then
by ``question`` ascending. The negative sign in front of "-pub_date" indicates by ``question`` ascending. The negative sign in front of "-pub_date" indicates
descending order. Ascending order is implied. To order randomly, use "?", like descending order. Ascending order is implied. To order randomly, use "?", like
so:: so::
polls.get_list(order_by=['?']) Poll.objects.order_by=(['?'])
To order by a field in a different table, add the other table's name and a dot, To order by a field in a different table, add the other table's name and a dot,
like so:: like so::
choices.get_list(order_by=('polls.pub_date', 'choice')) Choice.objects.all().order_by=('Poll.pub_date', 'choice')
There's no way to specify whether ordering should be case sensitive. With There's no way to specify whether ordering should be case sensitive. With
respect to case-sensitivity, Django will order results however your database respect to case-sensitivity, Django will order results however your database
@ -321,15 +430,15 @@ Relationships (joins)
===================== =====================
Joins may implicitly be performed by following relationships: Joins may implicitly be performed by following relationships:
``choices.get_list(poll__slug__exact="eggs")`` fetches a list of ``Choice`` ``Choice.objects.filter(poll__slug="eggs")`` fetches a list of ``Choice``
objects where the associated ``Poll`` has a slug of ``eggs``. Multiple levels objects where the associated ``Poll`` has a slug of ``eggs``. Multiple levels
of joins are allowed. of joins are allowed.
Given an instance of an object, related objects can be looked-up directly using Given an instance of an object, related objects can be looked-up directly using
convenience functions. For example, if ``p`` is a ``Poll`` instance, convenience functions. For example, if ``p`` is a ``Poll`` instance,
``p.get_choice_list()`` will return a list of all associated choices. Astute ``p.choice_set.all()`` will return a list of all associated choices. Astute
readers will note that this is the same as readers will note that this is the same as
``choices.get_list(poll__id__exact=p.id)``, except clearer. ``Choice.objects.filter(poll__id=p.id)``, except clearer.
Each type of relationship creates a set of methods on each object in the Each type of relationship creates a set of methods on each object in the
relationship. These methods are created in both directions, so objects that are relationship. These methods are created in both directions, so objects that are
@ -342,12 +451,12 @@ One-to-one relations
Each object in a one-to-one relationship will have a ``get_relatedobjectname()`` Each object in a one-to-one relationship will have a ``get_relatedobjectname()``
method. For example:: method. For example::
class Place(meta.Model): class Place(models.Model):
# ... # ...
class Restaurant(meta.Model): class Restaurant(models.Model):
# ... # ...
the_place = meta.OneToOneField(places.Place) the_place = models.OneToOneField(Place)
In the above example, each ``Place`` will have a ``get_restaurant()`` method, In the above example, each ``Place`` will have a ``get_restaurant()`` method,
and each ``Restaurant`` will have a ``get_the_place()`` method. and each ``Restaurant`` will have a ``get_the_place()`` method.
@ -359,7 +468,7 @@ In each many-to-one relationship, the related object will have a
``get_relatedobject()`` method, and the related-to object will have ``get_relatedobject()`` method, and the related-to object will have
``get_relatedobject()``, ``get_relatedobject_list()``, and ``get_relatedobject()``, ``get_relatedobject_list()``, and
``get_relatedobject_count()`` methods (the same as the module-level ``get_relatedobject_count()`` methods (the same as the module-level
``get_object()``, ``get_list()``, and ``get_count()`` methods). ``get_object()``, ``filter()``, and ``get_count()`` methods).
In the poll example above, here are the available choice methods on a ``Poll`` object ``p``:: In the poll example above, here are the available choice methods on a ``Poll`` object ``p``::
@ -399,50 +508,37 @@ queries, but it means that later use of relationships is much faster.
For example, using the Poll and Choice models from above, if you do the following:: For example, using the Poll and Choice models from above, if you do the following::
c = choices.get_object(id__exact=5, select_related=True) c = Choice.objects.get(id=5, select_related=True)
Then subsequent calls to ``c.get_poll()`` won't hit the database. Then subsequent calls to ``c.get_poll()`` won't hit the database.
Note that ``select_related`` follows foreign keys as far as possible. If you have the Note that ``select_related`` follows foreign keys as far as possible. If you have the
following models:: following models::
class Poll(meta.Model): class Poll(models.Model):
# ... # ...
class Choice(meta.Model): class Choice(models.Model):
# ... # ...
poll = meta.ForeignKey(Poll) poll = models.ForeignKey(Poll)
class SingleVote(meta.Model): class SingleVote(meta.Model):
# ... # ...
choice = meta.ForeignKey(Choice) choice = models.ForeignKey(Choice)
then a call to ``singlevotes.get_object(id__exact=4, select_related=True)`` will then a call to ``singlevotes.get_object(id=4, select_related=True)`` will
cache the related choice *and* the related poll:: cache the related choice *and* the related poll::
>>> sv = singlevotes.get_object(id__exact=4, select_related=True) >>> sv = singlevotes.get_object(id=4, select_related=True)
>>> c = sv.get_choice() # Doesn't hit the database. >>> c = sv.get_choice() # Doesn't hit the database.
>>> p = c.get_poll() # Doesn't hit the database. >>> p = c.get_poll() # Doesn't hit the database.
>>> sv = singlevotes.get_object(id__exact=4) # Note no "select_related". >>> sv = singlevotes.get_object(id=4) # Note no "select_related".
>>> c = sv.get_choice() # Hits the database. >>> c = sv.get_choice() # Hits the database.
>>> p = c.get_poll() # Hits the database. >>> p = c.get_poll() # Hits the database.
Limiting selected rows
======================
The ``limit``, ``offset``, and ``distinct`` keywords can be used to control Extra lookup options
which rows are returned. Both ``limit`` and ``offset`` should be integers which
will be directly passed to the SQL ``LIMIT``/``OFFSET`` commands.
If ``distinct`` is True, only distinct rows will be returned. This is equivalent
to a ``SELECT DISTINCT`` SQL clause. You can use this with ``get_values()`` to
get distinct values. For example, this returns the distinct first_names::
>>> people.get_values(fields=['first_name'], distinct=True)
[{'first_name': 'Adrian'}, {'first_name': 'Jacob'}, {'first_name': 'Simon'}]
Other lookup options
==================== ====================
There are a few other ways of more directly controlling the generated SQL There are a few other ways of more directly controlling the generated SQL
@ -450,6 +546,7 @@ for the lookup. Note that by definition these extra lookups may not be
portable to different database engines (because you're explicitly writing portable to different database engines (because you're explicitly writing
SQL code) and should be avoided if possible.: SQL code) and should be avoided if possible.:
``params`` ``params``
---------- ----------
@ -465,7 +562,7 @@ The ``select`` keyword allows you to select extra fields. This should be a
dictionary mapping attribute names to a SQL clause to use to calculate that dictionary mapping attribute names to a SQL clause to use to calculate that
attribute. For example:: attribute. For example::
polls.get_list( Poll.objects.extra(
select={ select={
'choice_count': 'SELECT COUNT(*) FROM choices WHERE poll_id = polls.id' 'choice_count': 'SELECT COUNT(*) FROM choices WHERE poll_id = polls.id'
} }
@ -488,7 +585,8 @@ are "AND"ed to any other search criteria.
For example:: For example::
polls.get_list(question__startswith='Who', where=['id IN (3, 4, 5, 20)']) Poll.objects.filter(
question__startswith='Who').extra(where=['id IN (3, 4, 5, 20)'])
...translates (roughly) into the following SQL: ...translates (roughly) into the following SQL:
@ -501,7 +599,7 @@ Once you've retrieved an object from the database using any of the above
options, changing it is extremely easy. Make changes directly to the options, changing it is extremely easy. Make changes directly to the
objects fields, then call the object's ``save()`` method:: objects fields, then call the object's ``save()`` method::
>>> p = polls.get_object(id__exact=15) >>> p = Polls.objects.get(id__exact=15)
>>> p.slug = "new_slug" >>> p.slug = "new_slug"
>>> p.pub_date = datetime.datetime.now() >>> p.pub_date = datetime.datetime.now()
>>> p.save() >>> p.save()
@ -512,7 +610,7 @@ Creating new objects
Creating new objects (i.e. ``INSERT``) is done by creating new instances Creating new objects (i.e. ``INSERT``) is done by creating new instances
of objects then calling save() on them:: of objects then calling save() on them::
>>> p = polls.Poll(slug="eggs", >>> p = Poll(slug="eggs",
... question="How do you like your eggs?", ... question="How do you like your eggs?",
... pub_date=datetime.datetime.now(), ... pub_date=datetime.datetime.now(),
... expire_date=some_future_date) ... expire_date=some_future_date)
@ -532,7 +630,7 @@ Related objects (e.g. ``Choices``) are created using convenience functions::
Each of those ``add_choice`` methods is equivalent to (but much simpler than):: Each of those ``add_choice`` methods is equivalent to (but much simpler than)::
>>> c = polls.Choice(poll_id=p.id, choice="Over easy", votes=0) >>> c = Choice(poll_id=p.id, choice="Over easy", votes=0)
>>> c.save() >>> c.save()
Note that when using the `add_foo()`` methods, you do not give any value Note that when using the `add_foo()`` methods, you do not give any value
@ -554,16 +652,7 @@ used for get_object and other query methods. For example::
>>> Polls.objects.delete(pub_date__year=2005) >>> Polls.objects.delete(pub_date__year=2005)
would bulk delete all Polls with a year of 2005. A bulk delete call with no would bulk delete all Polls with a year of 2005.
parameters would theoretically delete all data in the table. To prevent
accidental obliteration of a database, a bulk delete query with no parameters
will throw an exception. If you actually want to delete all the data in a
table, you must add a ``DELETE_ALL=True`` argument to your query.
For example::
>>> Polls.objects.delete(DELETE_ALL=True)
would remove all Poll instances from the database.
Comparing objects Comparing objects
================= =================
@ -655,14 +744,14 @@ returns an empty string.
get_FOO_size() get_FOO_size()
-------------- --------------
For every ``FileField``, the object will have a ``get_FOO_size()`` method, For every ``FileField``, the object will have a ``get_FOO_filename()`` method,
where ``FOO`` is the name of the field. This returns the size of the file, in where ``FOO`` is the name of the field. This returns the size of the file, in
bytes. (Behind the scenes, it uses ``os.path.getsize``.) bytes. (Behind the scenes, it uses ``os.path.getsize``.)
save_FOO_file(filename, raw_contents) save_FOO_file(filename, raw_contents)
------------------------------------- -------------------------------------
For every ``FileField``, the object will have a ``save_FOO_file()`` method, For every ``FileField``, the object will have a ``get_FOO_filename()`` method,
where ``FOO`` is the name of the field. This saves the given file to the where ``FOO`` is the name of the field. This saves the given file to the
filesystem, using the given filename. If a file with the given filename already filesystem, using the given filename. If a file with the given filename already
exists, Django adds an underscore to the end of the filename (but before the exists, Django adds an underscore to the end of the filename (but before the
@ -675,49 +764,3 @@ For every ``ImageField``, the object will have ``get_FOO_height()`` and
``get_FOO_width()`` methods, where ``FOO`` is the name of the field. This ``get_FOO_width()`` methods, where ``FOO`` is the name of the field. This
returns the height (or width) of the image, as an integer, in pixels. returns the height (or width) of the image, as an integer, in pixels.
Extra module functions
======================
In addition to every function described in "Basic lookup functions" above, a
model module might get any or all of the following methods:
dates(field, kind, order='ASC')
-------------------------------
Every manager has a ``dates()`` method, which returns a list of
``datetime.datetime`` objects representing all available dates with the given
filters (if any) and of the given scope, as defined by the ``kind`` argument.
``field`` should be the name of a ``DateField`` or ``DateTimeField`` of your
model.
``kind`` should be either ``"year"``, ``"month"`` or ``"day"``. Each
``datetime.datetime`` object in the result list is "truncated" to the given
``type``.
* ``"year"`` returns a list of all distinct year values for the field.
* ``"month"`` returns a list of all distinct year/month values for the field.
* ``"day"`` returns a list of all distinct year/month/day values for the field.
``order``, which defaults to ``'ASC'``, should be either ``"ASC"`` or ``"DESC"``.
This specifies how to order the results.
Here's an example, using the ``Poll`` model defined above::
>>> from datetime import datetime
>>> p1 = Poll(slug='whatsup', question="What's up?",
... pub_date=datetime(2005, 2, 20), expire_date=datetime(2005, 3, 20))
>>> p1.save()
>>> p2 = Poll(slug='name', question="What's your name?",
... pub_date=datetime(2005, 3, 20), expire_date=datetime(2005, 4, 20))
>>> p2.save()
>>> Poll.objects.dates('pub_date', 'year')
[datetime.datetime(2005, 1, 1)]
>>> Poll.objects.dates('pub_date', 'month')
[datetime.datetime(2005, 2, 1), datetime.datetime(2005, 3, 1)]
>>> Poll.objects.dates('pub_date', 'day')
[datetime.datetime(2005, 2, 20), datetime.datetime(2005, 3, 20)]
>>> Poll.objects.dates('pub_date', 'day', order='DESC')
[datetime.datetime(2005, 3, 20), datetime.datetime(2005, 2, 20)]
>>> Poll.objects.filter(question__contains='name').dates('pub_date', 'day')
[datetime.datetime(2005, 3, 20)]