mirror of
https://github.com/django/django.git
synced 2025-07-04 09:49:12 +00:00
newforms-admin: Merged from trunk up to [7491].
git-svn-id: http://code.djangoproject.com/svn/django/branches/newforms-admin@7492 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
678b9a6f5a
commit
738e6d986b
@ -282,31 +282,9 @@ class ChangeList(object):
|
|||||||
qs = qs.select_related()
|
qs = qs.select_related()
|
||||||
break
|
break
|
||||||
|
|
||||||
# Calculate lookup_order_field.
|
|
||||||
# If the order-by field is a field with a relationship, order by the
|
|
||||||
# value in the related table.
|
|
||||||
lookup_order_field = self.order_field
|
|
||||||
order_type = self.order_type == 'desc' and '-' or ''
|
|
||||||
try:
|
|
||||||
f = self.lookup_opts.get_field(self.order_field, many_to_many=False)
|
|
||||||
except models.FieldDoesNotExist:
|
|
||||||
pass
|
|
||||||
else:
|
|
||||||
if isinstance(f.rel, models.OneToOneRel):
|
|
||||||
# For OneToOneFields, don't try to order by the related object's ordering criteria.
|
|
||||||
pass
|
|
||||||
elif isinstance(f.rel, models.ManyToOneRel):
|
|
||||||
rel_ordering = f.rel.to._meta.ordering and f.rel.to._meta.ordering[0] or f.rel.to._meta.pk.column
|
|
||||||
if rel_ordering[0] == '-':
|
|
||||||
rel_ordering = rel_ordering[1:]
|
|
||||||
order_type = not order_type and '-' or ''
|
|
||||||
lookup_order_field = '%s.%s' % (f.rel.to._meta.db_table, rel_ordering)
|
|
||||||
# FIXME: Must use select_related() becuase the lookup field may
|
|
||||||
# be in a table not otherwise referenced yet.
|
|
||||||
qs = qs.select_related()
|
|
||||||
|
|
||||||
# Set ordering.
|
# Set ordering.
|
||||||
qs = qs.order_by(order_type + lookup_order_field)
|
if self.order_field:
|
||||||
|
qs = qs.order_by('%s%s' % ((self.order_type == 'desc' and '-' or ''), self.order_field))
|
||||||
|
|
||||||
# Apply keyword searches.
|
# Apply keyword searches.
|
||||||
def construct_search(field_name):
|
def construct_search(field_name):
|
||||||
|
@ -284,6 +284,7 @@ class QuerySet(object):
|
|||||||
query = self.query.clone(sql.UpdateQuery)
|
query = self.query.clone(sql.UpdateQuery)
|
||||||
query.add_update_values(kwargs)
|
query.add_update_values(kwargs)
|
||||||
query.execute_sql(None)
|
query.execute_sql(None)
|
||||||
|
transaction.commit_unless_managed()
|
||||||
self._result_cache = None
|
self._result_cache = None
|
||||||
update.alters_data = True
|
update.alters_data = True
|
||||||
|
|
||||||
|
@ -28,7 +28,7 @@ NULLABLE = 6
|
|||||||
MULTI = 'multi'
|
MULTI = 'multi'
|
||||||
SINGLE = 'single'
|
SINGLE = 'single'
|
||||||
|
|
||||||
ORDER_PATTERN = re.compile(r'\?|[-+]?\w+$')
|
ORDER_PATTERN = re.compile(r'\?|[-+]?[.\w]+$')
|
||||||
ORDER_DIR = {
|
ORDER_DIR = {
|
||||||
'ASC': ('ASC', 'DESC'),
|
'ASC': ('ASC', 'DESC'),
|
||||||
'DESC': ('DESC', 'ASC')}
|
'DESC': ('DESC', 'ASC')}
|
||||||
|
@ -95,7 +95,7 @@ class UpdateQuery(Query):
|
|||||||
|
|
||||||
def _setup_query(self):
|
def _setup_query(self):
|
||||||
"""
|
"""
|
||||||
Runs on initialisation and after cloning. Any attributes that would
|
Runs on initialization and after cloning. Any attributes that would
|
||||||
normally be set in __init__ should go in here, instead, so that they
|
normally be set in __init__ should go in here, instead, so that they
|
||||||
are also set up after a clone() call.
|
are also set up after a clone() call.
|
||||||
"""
|
"""
|
||||||
@ -349,6 +349,7 @@ class DateQuery(Query):
|
|||||||
self.connection.ops.date_trunc_sql)
|
self.connection.ops.date_trunc_sql)
|
||||||
self.select = [select]
|
self.select = [select]
|
||||||
self.select_fields = [None]
|
self.select_fields = [None]
|
||||||
|
self.select_related = False # See #7097.
|
||||||
self.distinct = True
|
self.distinct = True
|
||||||
self.order_by = order == 'ASC' and [1] or [-1]
|
self.order_by = order == 'ASC' and [1] or [-1]
|
||||||
|
|
||||||
|
@ -392,7 +392,7 @@ This returns the sixth through tenth objects (``OFFSET 5 LIMIT 5``)::
|
|||||||
Entry.objects.all()[5:10]
|
Entry.objects.all()[5:10]
|
||||||
|
|
||||||
You can also slice from the item ''N'' to the end of the queryset. For
|
You can also slice from the item ''N'' to the end of the queryset. For
|
||||||
example, to return everything from the fixth item onwards::
|
example, to return everything from the sixth item onwards::
|
||||||
|
|
||||||
Entry.objects.all()[5:]
|
Entry.objects.all()[5:]
|
||||||
|
|
||||||
@ -527,7 +527,7 @@ applied to a query, not even the default ordering, call ``order_by()`` with no
|
|||||||
parameters.
|
parameters.
|
||||||
|
|
||||||
**New in Django development version:** The syntax for ordering across related
|
**New in Django development version:** The syntax for ordering across related
|
||||||
models has changed. See the `Django 0.96 documentation`_ for the old behaviour.
|
models has changed. See the `Django 0.96 documentation`_ for the old behavior.
|
||||||
|
|
||||||
.. _Django 0.96 documentation: http://www.djangoproject.com/documentation/0.96/model-api/#floatfield
|
.. _Django 0.96 documentation: http://www.djangoproject.com/documentation/0.96/model-api/#floatfield
|
||||||
|
|
||||||
@ -540,9 +540,9 @@ backend normally orders them.
|
|||||||
|
|
||||||
**New in Django development version**
|
**New in Django development version**
|
||||||
|
|
||||||
If you want to reverse the order in which a queryset's elements are returned,
|
Use the ``reverse()`` method to reverse the order in which a queryset's
|
||||||
you can use the ``reverse()`` method. Calling ``reverse()`` a second time
|
elements are returned. Calling ``reverse()`` a second time restores the
|
||||||
restores the ordering back to the normal direction.
|
ordering back to the normal direction.
|
||||||
|
|
||||||
To retrieve the ''last'' five items in a queryset, you could do this::
|
To retrieve the ''last'' five items in a queryset, you could do this::
|
||||||
|
|
||||||
@ -552,7 +552,7 @@ Note that this is not quite the same as slicing from the end of a sequence in
|
|||||||
Python. The above example will return the last item first, then the
|
Python. The above example will return the last item first, then the
|
||||||
penultimate item and so on. If we had a Python sequence and looked at
|
penultimate item and so on. If we had a Python sequence and looked at
|
||||||
``seq[:-5]``, we would see the fifth-last item first. Django doesn't support
|
``seq[:-5]``, we would see the fifth-last item first. Django doesn't support
|
||||||
that mode of access (slicing from the end), since it is not possible to do it
|
that mode of access (slicing from the end), because it's not possible to do it
|
||||||
efficiently in SQL.
|
efficiently in SQL.
|
||||||
|
|
||||||
``distinct()``
|
``distinct()``
|
||||||
@ -570,7 +570,7 @@ query spans multiple tables, it's possible to get duplicate results when a
|
|||||||
.. note::
|
.. note::
|
||||||
Any fields used in an ``order_by()`` call are included in the SQL
|
Any fields used in an ``order_by()`` call are included in the SQL
|
||||||
``SELECT`` columns. This can sometimes lead to unexpected results when
|
``SELECT`` columns. This can sometimes lead to unexpected results when
|
||||||
used in conjuntion with ``distinct()``. If you order by fields from a
|
used in conjunction with ``distinct()``. If you order by fields from a
|
||||||
related model, those fields will be added to the selected columns and they
|
related model, those fields will be added to the selected columns and they
|
||||||
may make otherwise duplicate rows appear to be distinct. Since the extra
|
may make otherwise duplicate rows appear to be distinct. Since the extra
|
||||||
columns don't appear in the returned results (they are only there to
|
columns don't appear in the returned results (they are only there to
|
||||||
@ -683,7 +683,7 @@ dictionaries, it returns a list of tuples. Each tuple contains the value from
|
|||||||
the respective field passed into the ``values_list()`` call -- so the first
|
the respective field passed into the ``values_list()`` call -- so the first
|
||||||
item is the first field, etc. For example::
|
item is the first field, etc. For example::
|
||||||
|
|
||||||
>>> Entry.objects.values_list('id', 'headling')
|
>>> Entry.objects.values_list('id', 'headline')
|
||||||
[(1, u'First entry'), ...]
|
[(1, u'First entry'), ...]
|
||||||
|
|
||||||
If you only pass in a single field, you can also pass in the ``flat``
|
If you only pass in a single field, you can also pass in the ``flat``
|
||||||
@ -837,7 +837,7 @@ models. In these cases, you can pass the related field names to
|
|||||||
``select_related()`` and it will only follow those relations. You can even do
|
``select_related()`` and it will only follow those relations. You can even do
|
||||||
this for models that are more than one relation away by separating the field
|
this for models that are more than one relation away by separating the field
|
||||||
names with double underscores, just as for filters. For example, if we have
|
names with double underscores, just as for filters. For example, if we have
|
||||||
thise model::
|
this model::
|
||||||
|
|
||||||
class Room(models.Model):
|
class Room(models.Model):
|
||||||
# ...
|
# ...
|
||||||
@ -1660,7 +1660,7 @@ entry. The entries select by the second filter may or may not be the same as
|
|||||||
the entries in the first filter. We are filtering the ``Blog`` items with each
|
the entries in the first filter. We are filtering the ``Blog`` items with each
|
||||||
filter statement, not the ``Entry`` items.
|
filter statement, not the ``Entry`` items.
|
||||||
|
|
||||||
All of this behaviour also applies to ``exclude()``: all the conditions in a
|
All of this behavior also applies to ``exclude()``: all the conditions in a
|
||||||
single ``exclude()`` statement apply to a single instance (if those conditions
|
single ``exclude()`` statement apply to a single instance (if those conditions
|
||||||
are talking about the same multi-valued relation). Conditions in subsequent
|
are talking about the same multi-valued relation). Conditions in subsequent
|
||||||
``filter()`` or ``exclude()`` calls that refer to the same relation may end up
|
``filter()`` or ``exclude()`` calls that refer to the same relation may end up
|
||||||
@ -2101,24 +2101,24 @@ Updating multiple objects at once
|
|||||||
**New in Django development version**
|
**New in Django development version**
|
||||||
|
|
||||||
Sometimes you want to set a field to a particular value for all the objects in
|
Sometimes you want to set a field to a particular value for all the objects in
|
||||||
a queryset. You can do this with the ``update()`` method. For example::
|
a ``QuerySet``. You can do this with the ``update()`` method. For example::
|
||||||
|
|
||||||
# Update all the headlings to the same value.
|
# Update all the headlines with pub_date in 2007.
|
||||||
Entry.objects.all().update(headline='Everything is the same')
|
Entry.objects.filter(pub_date__year=2007).update(headline='Everything is the same')
|
||||||
|
|
||||||
You can only set non-relation fields and ``ForeignKey`` fields using this
|
You can only set non-relation fields and ``ForeignKey`` fields using this
|
||||||
method and the value you set the field to must be a normal Python value (you
|
method, and the value you set the field to must be a hard-coded Python value
|
||||||
can't set a field to be equal to some other field at the moment).
|
(i.e., you can't set a field to be equal to some other field at the moment).
|
||||||
|
|
||||||
To update ``ForeignKey`` fields, set the new value to be the new model
|
To update ``ForeignKey`` fields, set the new value to be the new model
|
||||||
instance you want to point to. Example::
|
instance you want to point to. Example::
|
||||||
|
|
||||||
b = Blog.objects.get(pk=1)
|
b = Blog.objects.get(pk=1)
|
||||||
# Make all entries belong to this blog.
|
# Change every Entry so that it belongs to this Blog.
|
||||||
Entry.objects.all().update(blog=b)
|
Entry.objects.all().update(blog=b)
|
||||||
|
|
||||||
The ``update()`` method is applied instantly and doesn't return anything
|
The ``update()`` method is applied instantly and doesn't return anything
|
||||||
(similar to ``delete()``). The only restriction on the queryset that is
|
(similar to ``delete()``). The only restriction on the ``QuerySet`` that is
|
||||||
updated is that it can only access one database table, the model's main
|
updated is that it can only access one database table, the model's main
|
||||||
table. So don't try to filter based on related fields or anything like that;
|
table. So don't try to filter based on related fields or anything like that;
|
||||||
it won't work.
|
it won't work.
|
||||||
|
@ -52,7 +52,7 @@ Some technical notes:
|
|||||||
* The name of the table, ``myapp_person``, is automatically derived from
|
* The name of the table, ``myapp_person``, is automatically derived from
|
||||||
some model metadata but can be overridden. See `Table names`_ below.
|
some model metadata but can be overridden. See `Table names`_ below.
|
||||||
* An ``id`` field is added automatically, but this behavior can be
|
* An ``id`` field is added automatically, but this behavior can be
|
||||||
overriden. See `Automatic primary key fields`_ below.
|
overridden. See `Automatic primary key fields`_ below.
|
||||||
* The ``CREATE TABLE`` SQL in this example is formatted using PostgreSQL
|
* The ``CREATE TABLE`` SQL in this example is formatted using PostgreSQL
|
||||||
syntax, but it's worth noting Django uses SQL tailored to the database
|
syntax, but it's worth noting Django uses SQL tailored to the database
|
||||||
backend specified in your `settings file`_.
|
backend specified in your `settings file`_.
|
||||||
@ -2194,7 +2194,7 @@ Multi-table inheritance
|
|||||||
|
|
||||||
The second type of model inheritance supported by Django is when each model in
|
The second type of model inheritance supported by Django is when each model in
|
||||||
the hierarchy is a model all by itself. Each model corresponds to its own
|
the hierarchy is a model all by itself. Each model corresponds to its own
|
||||||
database table and can be queried and created indvidually. The inheritance
|
database table and can be queried and created individually. The inheritance
|
||||||
relationship introduces links between the child model and each of its parents
|
relationship introduces links between the child model and each of its parents
|
||||||
(via an automatically created ``OneToOneField``). For example::
|
(via an automatically created ``OneToOneField``). For example::
|
||||||
|
|
||||||
@ -2242,7 +2242,7 @@ parent: if the child does not specify an ``ordering`` attribute or a
|
|||||||
``get_latest_by`` attribute, it will inherit these from its parent.
|
``get_latest_by`` attribute, it will inherit these from its parent.
|
||||||
|
|
||||||
If the parent has an ordering and you don't want the child to have any natural
|
If the parent has an ordering and you don't want the child to have any natural
|
||||||
ordering, you can explicity set it to be empty::
|
ordering, you can explicitly set it to be empty::
|
||||||
|
|
||||||
class ChildModel(ParentModel):
|
class ChildModel(ParentModel):
|
||||||
...
|
...
|
||||||
|
@ -246,7 +246,7 @@ FieldError: Cannot resolve keyword 'reporter_id' into field. Choices are: headli
|
|||||||
>>> Reporter.objects.filter(article__reporter__exact=r).distinct()
|
>>> Reporter.objects.filter(article__reporter__exact=r).distinct()
|
||||||
[<Reporter: John Smith>]
|
[<Reporter: John Smith>]
|
||||||
|
|
||||||
# Check that implied __exact also works
|
# Check that implied __exact also works.
|
||||||
>>> Reporter.objects.filter(article__reporter=r).distinct()
|
>>> Reporter.objects.filter(article__reporter=r).distinct()
|
||||||
[<Reporter: John Smith>]
|
[<Reporter: John Smith>]
|
||||||
|
|
||||||
@ -266,11 +266,24 @@ True
|
|||||||
>>> Reporter.objects.order_by('first_name')
|
>>> Reporter.objects.order_by('first_name')
|
||||||
[<Reporter: John Smith>]
|
[<Reporter: John Smith>]
|
||||||
|
|
||||||
# Deletes using a join in the query
|
# You can delete using a JOIN in the query.
|
||||||
>>> Reporter.objects.filter(article__headline__startswith='This').delete()
|
>>> Reporter.objects.filter(article__headline__startswith='This').delete()
|
||||||
>>> Reporter.objects.all()
|
>>> Reporter.objects.all()
|
||||||
[]
|
[]
|
||||||
>>> Article.objects.all()
|
>>> Article.objects.all()
|
||||||
[]
|
[]
|
||||||
|
|
||||||
|
# Check that Article.objects.select_related().dates() works properly when
|
||||||
|
# there are multiple Articles with the same date but different foreign-key
|
||||||
|
# objects (Reporters).
|
||||||
|
>>> r1 = Reporter.objects.create(first_name='Mike', last_name='Royko', email='royko@suntimes.com')
|
||||||
|
>>> r2 = Reporter.objects.create(first_name='John', last_name='Kass', email='jkass@tribune.com')
|
||||||
|
>>> a1 = Article.objects.create(headline='First', pub_date=datetime(1980, 4, 23), reporter=r1)
|
||||||
|
>>> a2 = Article.objects.create(headline='Second', pub_date=datetime(1980, 4, 23), reporter=r2)
|
||||||
|
>>> Article.objects.select_related().dates('pub_date', 'day')
|
||||||
|
[datetime.datetime(1980, 4, 23, 0, 0)]
|
||||||
|
>>> Article.objects.select_related().dates('pub_date', 'month')
|
||||||
|
[datetime.datetime(1980, 4, 1, 0, 0)]
|
||||||
|
>>> Article.objects.select_related().dates('pub_date', 'year')
|
||||||
|
[datetime.datetime(1980, 1, 1, 0, 0)]
|
||||||
"""}
|
"""}
|
||||||
|
@ -654,5 +654,9 @@ Bug #7045 -- extra tables used to crash SQL construction on the second use.
|
|||||||
>>> s = qs.query.as_sql()
|
>>> s = qs.query.as_sql()
|
||||||
>>> s = qs.query.as_sql() # test passes if this doesn't raise an exception.
|
>>> s = qs.query.as_sql() # test passes if this doesn't raise an exception.
|
||||||
|
|
||||||
|
Bug #7098 -- Make sure semi-deprecated ordering by related models syntax still
|
||||||
|
works.
|
||||||
|
>>> Item.objects.values('note__note').order_by('queries_note.note', 'id')
|
||||||
|
[{'note__note': u'n2'}, {'note__note': u'n3'}, {'note__note': u'n3'}, {'note__note': u'n3'}]
|
||||||
"""}
|
"""}
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user