When using "select distinct" all ordering columns must be part of the output
(select) columns. We were previously just throwing away ordering columns that
weren't included, but there are some cases where they are needed and it's
difficult to add them in manually. So now the default behaviour is to append
any missing columns.
This can affect the output of distinct() if complicated order_by() constructs
are used, so the documentation has been updated with an explanation of what's
going on there.
Fixed#7070.
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7455 bcc190cf-cafb-0310-a4f2-bffc1f526a37
extra(tables=...). This is already a problem in trunk and it's pretty much
impossible to work around in a non-complex way, so it's user beware (it's
usually easy enough to avoid the problems).
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7453 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Suggested by Michael Trier. It's more consistent with order_by, select_related,
etc. This is backwards incompatible for people previously using this method on
the branch (the method doesn't exist on trunk, so it's very minor).
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7451 bcc190cf-cafb-0310-a4f2-bffc1f526a37
parameters are substituted in correctly in all cases. This introduces an extra
argument to extra() for this purpose; no alternative there.
Also fixed values() to work if you don't specify *all* the extra select aliases
in the values() call.
Refs #3141.
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7340 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Some people will shoot themselves in the foot with this. That's bad luck.
The reason we need it is because some data semantics cannot be expressed in
Django's ORM and that shouldn't prevent ordering on that data. For example,
filtering suburbs by a geographic region and then ordering on the suburb names.
The names might not be unique outside that region, but unique inside it. Django
cannot know that (you can't tell the model about it), so we trust the caller.
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7285 bcc190cf-cafb-0310-a4f2-bffc1f526a37
across inherited models.
Completely by accident, this also allows values() queries to include fields
from related models, providing it is crossing a single-valued relation
(one-to-one, many-to-one). Many-to-many values() fields still aren't supported,
since that requires actual thinking. So this refs #5768.
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7230 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This means subclasses can override save() without needing to worry about
passing around the internal parameters (an issue for subclassable models, which
would have meant every model, since you don't know when somebody will subclass
your model).
Slightly backwards incompatible, since it moves "raw" back to being part of the
internal API (it's only needed by the serializer and was intended to be
internal use only). If external code really needs this, they can call
Model.save_base() and pass in raw there.
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7221 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This adds both types of model inheritance: abstract base classes (ABCs) and
multi-table inheritance. See the documentation and tests / examples for details.
Still a few known bugs here, so don't file tickets (I know about them). Not
quite ready for prime-time usage, but it mostly works as expected.
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7126 bcc190cf-cafb-0310-a4f2-bffc1f526a37
They now share as much code as possible with ForeignKeys, but behave more or
less as they did before (the backwards incompatible change is that they are no
longer automatically primary keys -- so more than one per model is permitted).
The documentation still uses an example that is better suited to model
inheritance, but that will change in due course. Also, the admin interface
still shows them as read-only fields, which is probably wrong now, but that can
change on newforms-admin after this branch is merged into trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7096 bcc190cf-cafb-0310-a4f2-bffc1f526a37
moving SQL out of the core code. Only direct fields and foreign keys can be
updated in this fashion, since multi-table updates are very non-portable.
This also cleans up the API for the UpdateQuery class a bit. Still need to
change DeleteQuery to work similarly, I suspect.
Refs #4260.
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7043 bcc190cf-cafb-0310-a4f2-bffc1f526a37
