1
0
mirror of https://github.com/django/django.git synced 2025-07-04 17:59:13 +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:
Brian Rosner 2008-04-28 04:28:59 +00:00
parent 678b9a6f5a
commit 738e6d986b
8 changed files with 45 additions and 48 deletions

View File

@ -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):

View File

@ -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

View File

@ -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')}

View File

@ -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]

View File

@ -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.

View File

@ -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):
... ...

View File

@ -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)]
"""} """}

View File

@ -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'}]
"""} """}