This involves a slight change to the interaction of annotate() and values() clauses that specify a list of columns. See the docs for details.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9888 bcc190cf-cafb-0310-a4f2-bffc1f526a37
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.
* Malcolm Tredinnick for his invaluable review notes.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9792 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Previous behaviour was pretty stupid. Let's never speak of it again. New
behaviour both works and is documented.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9759 bcc190cf-cafb-0310-a4f2-bffc1f526a37
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
The last use of it was removed in r9641 (it's internal API) and it's been
broken since r7477, as there's no longer a maximum of one OneToOneField per
model, so anything relying on it contained subtle bugs.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9643 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
lookup in the serializable_value() method. This means that abstract
parents that are multi-table children of other models(no, really!!) now
work again.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9618 bcc190cf-cafb-0310-a4f2-bffc1f526a37
"value" for a field that is a relation to another model.
This part adds the utility method on Model that should help in general.Also
cleans up the slightly ugly mess from r8957.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9601 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Descriptors now return themselves when accessed via the class, as per standard
Python descriptors like property().
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9550 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
more than 20 objects.
This means that accidentally executing HugeStoryArchive.objects.all() at the
interactive prompt (or in the debug template) won't try to load all 4,233,010
stories into memory and print them out. That would previously cause resource
starvation and other "interesting" crashes.
If you really, really want the previous behaviour (e.g. in a doctest that
prints more than 20 items), display "list(qs)" instead of just "qs".
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9202 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
Also added documentation describing how manager inheritance works (and when
manager aren't inherited). Based on some patches from sebastian_noack and
emulbreh.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8851 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
I can't reproduce the original error leading to #8115 and the patch. However, the only harm this change could cause is to raise more `CyclicDependency` exceptions than strictly necessary. That's better than infinite loops, at least, and it's easier to clean up in the future when we figure out the actual fix.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8807 bcc190cf-cafb-0310-a4f2-bffc1f526a37
fields (the latter was causing problems). This allows these values in URLs
(e.g. the admin filtering).
Not an ideal solution to the problem, but will do the job for the time being.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8691 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Backwards incompatible if you are using manually-specific primary key values
and relying on the previously documented behaviour that the new values would
always exist in the database (i.e. it would update the existing entry).
Fixed#8419.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8670 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
* Removed `Manipulator`, `AutomaticManipulator`, and related classes.
* Removed oldforms specific bits from model fields:
* Removed `validator_list` and `core` arguments from constructors.
* Removed the methods:
* `get_manipulator_field_names`
* `get_manipulator_field_objs`
* `get_manipulator_fields`
* `get_manipulator_new_data`
* `prepare_field_objs_and_params`
* `get_follow`
* Renamed `flatten_data` method to `value_to_string` for better alignment with its use by the serialization framework, which was the only remaining code using `flatten_data`.
* Removed oldforms methods from `django.db.models.Options` class: `get_followed_related_objects`, `get_data_holders`, `get_follow`, and `has_field_type`.
* Removed oldforms-admin specific options from `django.db.models.fields.related` classes: `num_in_admin`, `min_num_in_admin`, `max_num_in_admin`, `num_extra_on_change`, and `edit_inline`.
* Serialization framework
* `Serializer.get_string_value` now calls the model fields' renamed `value_to_string` methods.
* Removed a special-casing of `models.DateTimeField` in `core.serializers.base.Serializer.get_string_value` that's handled by `django.db.models.fields.DateTimeField.value_to_string`.
* Removed `django.core.validators`:
* Moved `ValidationError` exception to `django.core.exceptions`.
* For the couple places that were using validators, brought over the necessary code to maintain the same functionality.
* Introduced a SlugField form field for validation and to compliment the SlugField model field (refs #8040).
* Removed an oldforms-style model creation hack (refs #2160).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8616 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
instances. We weren't skipping the correct output columns before processing
subsequent existing related instances. Thanks to mrmachine for the test case.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8598 bcc190cf-cafb-0310-a4f2-bffc1f526a37
used in "month" and "day" filters on date/datetime fields. Without this commit,
SQLite behaved inconsistently after [8494].
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8526 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
Karen Tracey
Russell Keith-Magee
Jacob Kaplan-Moss
Malcolm Tredinnick
Luke Plant
Ian Kelly
Brian Rosner
Gary Wilson Jr