p31829507
/
django
mirror of https://github.com/django/django.git
1
0
Fork 0
Code Issues 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
`AutoField documentation`_.)
.. _AutoField documentation: TODO: Link
.. _AutoField documentation: http://www.djangoproject.com/documentation/model_api/#autofield
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
executed.
filter(**kwargs)
~~~~~~~~~~~~~~~~
``filter(**kwargs)``
~~~~~~~~~~~~~~~~~~~~
Returns a new ``QuerySet`` containing objects that match the given lookup
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
underlying SQL statement.
exclude(**kwargs)
~~~~~~~~~~~~~~~~~
``exclude(**kwargs)``
~~~~~~~~~~~~~~~~~~~~~
Returns a new ``QuerySet`` containing objects that do *not* match the given
lookup parameters.
@ -364,8 +364,8 @@ In SQL terms, that evaluates to::
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
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
backend normally orders them.
distinct()
~~~~~~~~~~
``distinct()``
~~~~~~~~~~~~~~
Returns a new ``QuerySet`` that uses ``SELECT DISTINCT`` in its SQL query. This
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
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
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
individualism.
dates(field, kind, order='ASC')
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
``dates(field, kind, order='ASC')``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Returns a ``DateQuerySet`` -- a ``QuerySet`` that evaluates to a list of
``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')
[datetime.datetime(2005, 3, 20)]
select_related()
~~~~~~~~~~~~~~~~
``select_related()``
~~~~~~~~~~~~~~~~~~~~
Returns a ``QuerySet`` that will automatically "follow" foreign-key
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.
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
``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,
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
the format described in _`Field lookups`.
@ -671,8 +671,8 @@ The ``DoesNotExist`` exception inherits from
except ObjectDoesNotExist:
print "Either the entry or blog doesn't exist."
count()
~~~~~~~
``count()``
~~~~~~~~~~~
Returns an integer representing the number of objects in the database matching
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
problems.
in_bulk(id_list)
~~~~~~~~~~~~~~~~
``in_bulk(id_list)``
~~~~~~~~~~~~~~~~~~~~
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.
@ -711,8 +711,8 @@ Example::
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``
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.name == other_obj.name
========================================
THE REST OF THIS HAS NOT YET BEEN EDITED
========================================
OR lookups
==========