django.git/docs/db-api.txt, branch archive/attic/queryset-refactordjango
http://cgit.adnoto.dev/django.git/atom?h=archive%2Fattic%2Fqueryset-refactor2008-04-24T16:07:07Zqueryset-refactor: Changed the way order_by() and distinct() interact.2008-04-24T16:07:07ZMalcolm Tredinnickmalcolm.tredinnick@gmail.com2008-04-24T16:07:07Zurn:sha1:8a4e1de8b0573ce4330f7690fe5e9d786265e237
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
queryset-refactor: Added a note about using already present tables in2008-04-24T11:41:29ZMalcolm Tredinnickmalcolm.tredinnick@gmail.com2008-04-24T11:41:29Zurn:sha1:28b1c9c1c95fe6193e234f85f51ec593cac3b861
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
queryset-refactor: Renamed the Queryset method valueslist() to values_list.2008-04-24T11:11:30ZMalcolm Tredinnickmalcolm.tredinnick@gmail.com2008-04-24T11:11:30Zurn:sha1:9d6f0f9e1085d963d96168efaf07315613cb8cc0
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
queryset-refactor: Removed a warning about "experimental API", since there's2008-04-23T12:34:13ZMalcolm Tredinnickmalcolm.tredinnick@gmail.com2008-04-23T12:34:13Zurn:sha1:27b0a4c4e7cb491b24c802f00e06ae0c6b3cc57d
not really any obviously better way to do this. Let it stand.
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7448 bcc190cf-cafb-0310-a4f2-bffc1f526a37
queryset-refactor: Merged from trunk up to [7388].2008-04-01T00:28:15ZMalcolm Tredinnickmalcolm.tredinnick@gmail.com2008-04-01T00:28:15Zurn:sha1:4efe9675c5fd5a030737d957b3588184f06117fe
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7396 bcc190cf-cafb-0310-a4f2-bffc1f526a37
queryset-refactor: Fixed up extra(select=...) calls with parameters so that the2008-03-20T19:16:04ZMalcolm Tredinnickmalcolm.tredinnick@gmail.com2008-03-20T19:16:04Zurn:sha1:04da22633fcda983cb9ee69e63b2ebe99301b717
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
queryset-refactor: Implemented a way to differentiate between filtering on a2008-03-19T11:02:22ZMalcolm Tredinnickmalcolm.tredinnick@gmail.com2008-03-19T11:02:22Zurn:sha1:d20996b58dfde66d80d6728a70480c7e5caf7d48
single instance and filtering on multiple instances when spanning a
multi-valued relationship.
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7317 bcc190cf-cafb-0310-a4f2-bffc1f526a37
queryset-refactor: Undo [7220] and allow ordering on multi-valued field.2008-03-18T10:21:50ZMalcolm Tredinnickmalcolm.tredinnick@gmail.com2008-03-18T10:21:50Zurn:sha1:670be13986b74f252d479ee2b7f74da8655273f6
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
queryset-refactor: Refactored the way values() works so that it works properly2008-03-12T12:41:58ZMalcolm Tredinnickmalcolm.tredinnick@gmail.com2008-03-12T12:41:58Zurn:sha1:428450b7a90d92239b170160e5926f83085fa476
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
queryset-refactor: Reorganised Model.save() to differentiate between public and private parameters. Refs #6741.2008-03-11T05:36:10ZMalcolm Tredinnickmalcolm.tredinnick@gmail.com2008-03-11T05:36:10Zurn:sha1:3176bebffd7a7e3ba131da2d1b3f9776e159f0a8
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