innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

Fixed some ReST errors in docs/db-api.txt 

git-svn-id: http://code.djangoproject.com/svn/django/trunk@2810 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Adrian Holovaty 2006-05-02 01:55:25 +00:00
parent f69cf70ed8
commit aa84e3a0df
1 changed files with 25 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
docs/db-api.txt
View File

@ -81,7 +81,7 @@ There's no way to tell what the value of an ID will be before you call
unless you explicitly specify ``primary_key=True`` on a field. See the unless you explicitly specify ``primary_key=True`` on a field. See the
`AutoField documentation`_.) `AutoField documentation`_.)
.. _AutoField documentation: TODO: Link .. _AutoField documentation: http://www.djangoproject.com/documentation/model_api/#autofield
Explicitly specifying auto-primary-key values Explicitly specifying auto-primary-key values
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -321,8 +321,8 @@ Django provides a range of ``QuerySet`` refinement methods that modify either
the types of results returned by the ``QuerySet`` or the way its SQL query is the types of results returned by the ``QuerySet`` or the way its SQL query is
executed. executed.
filter(**kwargs) ``filter(**kwargs)``
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
Returns a new ``QuerySet`` containing objects that match the given lookup Returns a new ``QuerySet`` containing objects that match the given lookup
parameters. parameters.
@ -331,8 +331,8 @@ The lookup parameters (``**kwargs``) should be in the format described in
_`Field lookups` below. Multiple parameters are joined via ``AND`` in the _`Field lookups` below. Multiple parameters are joined via ``AND`` in the
underlying SQL statement. underlying SQL statement.
exclude(**kwargs) ``exclude(**kwargs)``
~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
Returns a new ``QuerySet`` containing objects that do *not* match the given Returns a new ``QuerySet`` containing objects that do *not* match the given
lookup parameters. lookup parameters.
@ -364,8 +364,8 @@ In SQL terms, that evaluates to::
Note the second example is more restrictive. Note the second example is more restrictive.
order_by(*fields) ``order_by(*fields)``
~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
By default, results returned by a ``QuerySet`` are ordered by the ordering By default, results returned by a ``QuerySet`` are ordered by the ordering
tuple given by the ``ordering`` option in the model's ``Meta``. You can tuple given by the ``ordering`` option in the model's ``Meta``. You can
@ -391,8 +391,8 @@ 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
backend normally orders them. backend normally orders them.
distinct() ``distinct()``
~~~~~~~~~~ ~~~~~~~~~~~~~~
Returns a new ``QuerySet`` that uses ``SELECT DISTINCT`` in its SQL query. This Returns a new ``QuerySet`` that uses ``SELECT DISTINCT`` in its SQL query. This
eliminates duplicate rows from the query results. eliminates duplicate rows from the query results.
@ -404,8 +404,8 @@ don't introduce the possibility of duplicate result rows.
However, if your query spans multiple tables, it's possible to get duplicate However, if your query spans multiple tables, it's possible to get duplicate
results when a ``QuerySet`` is evaluated. That's when you'd use ``distinct()``. results when a ``QuerySet`` is evaluated. That's when you'd use ``distinct()``.
values(*fields) ``values(*fields)``
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
Returns a ``ValuesQuerySet`` -- a ``QuerySet`` that evaluates to a list of Returns a ``ValuesQuerySet`` -- a ``QuerySet`` that evaluates to a list of
dictionaries instead of model-instance objects. dictionaries instead of model-instance objects.
@ -454,8 +454,8 @@ followed (optionally) by any output-affecting methods (such as ``values()``),
but it doesn't really matter. This is your chance to really flaunt your but it doesn't really matter. This is your chance to really flaunt your
individualism. individualism.
dates(field, kind, order='ASC') ``dates(field, kind, order='ASC')``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Returns a ``DateQuerySet`` -- a ``QuerySet`` that evaluates to a list of Returns a ``DateQuerySet`` -- a ``QuerySet`` that evaluates to a list of
``datetime.datetime`` objects representing all available dates of a particular ``datetime.datetime`` objects representing all available dates of a particular
@ -488,8 +488,8 @@ Examples::
>>> Entry.objects.filter(headline__contains='Lennon').dates('pub_date', 'day') >>> Entry.objects.filter(headline__contains='Lennon').dates('pub_date', 'day')
[datetime.datetime(2005, 3, 20)] [datetime.datetime(2005, 3, 20)]
select_related() ``select_related()``
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
Returns a ``QuerySet`` that will automatically "follow" foreign-key Returns a ``QuerySet`` that will automatically "follow" foreign-key
relationships, selecting that additional related-object data when it executes relationships, selecting that additional related-object data when it executes
@ -540,8 +540,8 @@ related ``Person`` *and* the related ``City``::
p = b.author # Hits the database. p = b.author # Hits the database.
c = p.hometown # Hits the database. c = p.hometown # Hits the database.
extra(select=None, where=None, params=None, tables=None) ``extra(select=None, where=None, params=None, tables=None)``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sometimes, the Django query syntax by itself can't easily express a complex Sometimes, the Django query syntax by itself can't easily express a complex
``WHERE`` clause. For these edge cases, Django provides the ``extra()`` ``WHERE`` clause. For these edge cases, Django provides the ``extra()``
@ -646,8 +646,8 @@ something *other than* a ``QuerySet``.
These methods do not use a cache (see _`Caching and QuerySets` below). Rather, These methods do not use a cache (see _`Caching and QuerySets` below). Rather,
they query the database each time they're called. they query the database each time they're called.
get(**kwargs) ``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`. the format described in _`Field lookups`.
@ -671,8 +671,8 @@ The ``DoesNotExist`` exception inherits from
except ObjectDoesNotExist: except ObjectDoesNotExist:
print "Either the entry or blog doesn't exist." print "Either the entry or blog doesn't exist."
count() ``count()``
~~~~~~~ ~~~~~~~~~~~
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 ``QuerySet``. ``count()`` never raises exceptions. the ``QuerySet``. ``count()`` never raises exceptions.
@ -694,8 +694,8 @@ Depending on which database you're using (e.g. PostgreSQL vs. MySQL),
is an underlying implementation quirk that shouldn't pose any real-world is an underlying implementation quirk that shouldn't pose any real-world
problems. problems.
in_bulk(id_list) ``in_bulk(id_list)``
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
Takes a list of primary-key values and returns a dictionary mapping each Takes a list of primary-key values and returns a dictionary mapping each
primary-key value to an instance of the object with the given ID. primary-key value to an instance of the object with the given ID.
@ -711,8 +711,8 @@ Example::
If you pass ``in_bulk()`` an empty list, you'll get an empty dictionary. If you pass ``in_bulk()`` an empty list, you'll get an empty dictionary.
latest(field_name=None) ``latest(field_name=None)``
~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
Returns the latest object in the table, by date, using the ``field_name`` Returns the latest object in the table, by date, using the ``field_name``
provided as the date field. provided as the date field.
@ -1106,14 +1106,6 @@ primary key field is called ``name``, these two statements are equivalent::
some_obj == other_obj some_obj == other_obj
some_obj.name == other_obj.name some_obj.name == other_obj.name
========================================
THE REST OF THIS HAS NOT YET BEEN EDITED
========================================
OR lookups OR lookups
========== ==========