Many thanks to:
* Nicolas Lara, who worked on this feature during the 2008 Google Summer of Code.
* Alex Gaynor for his help debugging and fixing a number of issues.
* Justin Bronn for his help integrating with contrib.gis.
* Karen Tracey for her help with cross-platform testing.
* Ian Kelly for his help testing and fixing Oracle support.
* Malcolm Tredinnick for his invaluable review notes.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9742 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This extends previous functionality that allowed passing Query objects as the
rvals to filters. You can now pass QuerySets, which requires less poking at
opaque attributes. See the documentation of the "__in" lookup type for the
details.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9701 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Extricated the code that works directly with SQL columns (standard
"where" stuff) from the the code that takes SQL fragments and combines
it with lookup types and values. The latter portion is now more
generally reusable. Any existing code that was poking at Query.having
will now break in very visible ways (no subtle miscalculations, which is
a good thing).
This patch, en passant, removes the existing "having" test, since the
new implementation requires more setting up than previously. The
aggregates support (currently in a separate codebase) has tests for this
functionality that work as a replacement for the removed test.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9700 bcc190cf-cafb-0310-a4f2-bffc1f526a37
that happens with MySQL when a "GROUP BY" clause is included. This is a
backend-specific operation, so any other databases requiring similar
encouragement can have a function added to their own backend code.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9637 bcc190cf-cafb-0310-a4f2-bffc1f526a37
backend.
This allows Querysets to be cached for Oracle and should provide a model for
adding pickling support to other (external) database backends that need a
custom Query class.
Thanks to Justin Bronn for some assistance with this patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9272 bcc190cf-cafb-0310-a4f2-bffc1f526a37
again later (order_by('foo')). Or, at least, it can now. Thanks to Ilya
Novoselov for diagnosing the problem here.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9206 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Any extra(select=...) columns can be ignored in the SQL for dates, since we are
only interested in extracting distinct date values. We were previously
including them by accident and it was generating incorrect SQL.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9091 bcc190cf-cafb-0310-a4f2-bffc1f526a37
"having" attributes, only the former was included in the resulting SQL, meaning
subclasses had to completely duplicate Query.as_sql() if they were using any
kind of grouping filtering on the results.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9007 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This was triggered by r8794, but was, in fact, fairly fragile before then. The
current fix is the correct way we should be doing this.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8898 bcc190cf-cafb-0310-a4f2-bffc1f526a37
sometimes also sharing aliases, instead of creating their own. This was
generating incorrect SQL.
No representative test for this fix yet because I haven't had time to write one
that fits in nicely with the test suite. But it works for the monstrous example
in #8790 and a bunch of other complex examples I've created locally. Will write
a test later.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8853 bcc190cf-cafb-0310-a4f2-bffc1f526a37
efficient than possible SQL in some odd cases (found via code inspection, not
any particular failing example).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8831 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Yes, this really is a commit that fixes an oversight in a commit that fixed an
oversight. One day I'll get it right.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8829 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Also comes with approximately 67% less stupidity in the table joins for
filtering on generic relations.
Fixed#5937, hopefully for good, this time.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8644 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This isn't a complete solution to this class of problem, but it will do for
1.0, which only has generic relations as a multicolumn type. A more general
multicolumn solution will be available after that release.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8608 bcc190cf-cafb-0310-a4f2-bffc1f526a37
fields no longer creates duplicate copies of the join table(s). Basically, this
means filters on the join table (for ManyToManyField(through=...)) and complex
filters in the normal (non-through) case don't produce incorrect or duplicate
results.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8472 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Though some attempts and backwards-compatibility were made, speed trumped compatibility. Thus, as usual, check BackwardsIncompatibleChanges for the complete list of backwards-incompatible changes.
Thanks to Jeremy Dunck and Keith Busell for the bulk of the work; some ideas from Brian Herring's previous work (refs #4561) were incorporated.
Documentation is, sigh, still forthcoming.
Fixes#6814 and #3951 (with the new dispatch_uid argument to connect).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8223 bcc190cf-cafb-0310-a4f2-bffc1f526a37
the prequisites are correctly initialised prior to using them. Only affects
Oracle and other db backends requiring resolve_columns() (e.g. MS SQL?)
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8112 bcc190cf-cafb-0310-a4f2-bffc1f526a37
match nothing). This allows for some more straightforward code in the admin
interface.
Fixed#7488 (all the debugging there was done by Brian Rosner, who narrowed it
down to the item in this patch).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8061 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Based on a patch from Justin Bronn.
The test in this patch most likely breaks on Oracle. That's another issue.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8053 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Russell Keith-Magee
Malcolm Tredinnick
Ian Kelly
Jacob Kaplan-Moss
Adrian Holovaty