The conditional processing decorator from r10114 wasn't parsing ETags
from an If-Match header correctly. Patch from Ivan Sagalaev (who also
did most of the work in r10114, before I rewrote parts of it and added
bonus bugs, although I forgot to thank him there).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10116 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This provides support for views that can have their ETag and/or Last-modified
values computed much more quickly than the view itself. Supports all HTTP
verbs (not just GET).
Documentation and tests need a little more fleshing out (I'm not happy with the
documentation at the moment, since it's a bit backwards), but the functionality
is correct.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10114 bcc190cf-cafb-0310-a4f2-bffc1f526a37
A custom manager on a related object that filtered away objects would prevent
those objects being deleted via the relation. This is now fixed.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10104 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Calling the super() version of __reduce__ in Model.__reduce__ led to infinite
loops in Python prior to 2.5. We don't do that any longer.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10099 bcc190cf-cafb-0310-a4f2-bffc1f526a37
In extreme cases, some fields are expensive to load from the database
(e.g. GIS fields requiring conversion, or large text fields). This
commit adds defer() and only() methods to querysets that allow the
caller to specify which fields should not be loaded unless they are
accessed.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10090 bcc190cf-cafb-0310-a4f2-bffc1f526a37
We can't use the default manager in Model.save_base(), since we need to
retrieve existing objects which might be filtered out by that manager. We now
always use a plain Manager instance at that point (or something that can
replace it, such as a GeoManager), making all existing rows in the
database visible to the saving code.
The logic for detecting a "suitable replacement" plain base is the same as for
related fields: if the use_for_related_fields is set on the manager subclass,
we can use it. The general requirement here is that we want a base class that
returns the appropriate QuerySet subclass, but does not restrict the rows
returned.
Fixed#8990, #9527.
Refs #2698 (which is not fixed by this change, but it's the first part of a
larger change to fix that bug.)
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10056 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Adding a get_db_prep_save() call to the UpdateQuery code path meant it
was being called twice if you updated an existing model attribute. This
change removes that double call and also makes TimeField.to_python() a
little more robust for the benefit of the Oracle backend (just in case).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10013 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Previously, you could explicitly assign None to a non-null ForeignKey
(or other) field when creating the model (Child(parent=None), etc). We
now throw an exception when you do that, which matches the behaviour
when you assign None to the attribute after creation.
Thanks to ales.zoulek@gmail.com and ondrej.kohout@gmail.com for some
analysis of this problem.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9983 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This fixes a broad class of bugs involving filters that look for missing
related models and fields. Most of them don't seem to have been reported
(the added tests cover the root cause). The exception is that this has
also fixed#9868.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9979 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Manually specifying both a OneToOneField(parent_link=True) and separate a
primary key field was causing invalid SQL to be generated. Thanks to Ramiro
Morales for some analysis on this one.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9971 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This includes a fairly large refactor of the update() query path (and
the initial portions of constructing the SQL for any query). The
previous code appears to have been only working more or less by accident
and was very fragile.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9967 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is like "safe", except it operates on the individual elements of a
sequence, rather than treating the whole argument as a string.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9952 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Some results were inadvertently being excluded if we were ordering across a
nullable relation which itself ordering by a non-nullable relation.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9916 bcc190cf-cafb-0310-a4f2-bffc1f526a37
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
* The new method uses an admin configuration option (`formfield_overrides`); this makes custom admin widgets especially easy.
* Refactored what was left of `formfield_for_dbfield` into a handful of smaller methods so that it's easier to hook in and return custom fields where needed.
* These `formfield_for_*` methods now pass around `request` so that you can easily modify fields based on request (as in #3987).
Fixes#8306, #3987, #9148.
Thanks to James Bennet for the original patch; Alex Gaynor and Brian Rosner also contributed.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9760 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
This change may be slightly backwards incompatible, if existing tests need to test transactional behavior, or if they rely on invalid assumptions or a specific test case ordering. For the first case, django.test.TransactionTestCase should be used. TransactionTestCase is also a quick fix to get around test case errors revealed by the new rollback approach, but a better long-term fix is to correct the test case. See the testing doc for full details.
Many thanks to:
* Marc Remolt for the initial proposal and implementation.
* Luke Plant for initial testing and improving the implementation.
* Ramiro Morales for feedback and help with tracking down a mysterious PostgreSQL issue.
* Eric Holscher for feedback regarding the effect of the change on the Ellington testsuite.
* Russell Keith-Magee for guidance and feedback from beginning to end.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9756 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 *is* backwards compatible, but `admin.site.root()` has been deprecated. The new style is `('^admin/', include(admin.site.urls))`; users will need to update their code to take advantage of the new customizable admin URLs.
Thanks to Alex Gaynor.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9739 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
Astute readers will notice that the patch originally called this `default`; after consideration I decided that `empty` is a very slightly better color for this particular bikeshed.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9530 bcc190cf-cafb-0310-a4f2-bffc1f526a37
passed in for the connector. This was contrary to what the documentation
for autoescaping said and to what every other filter does with literal
strings as arguments.
This is backwards incompatible for the situation of the literal string
containing one of the five special HTML characters: if you were writing
{{ foo|join:"&" }}, you now have to write {{ foo| join:"&" }}.
Previous behaviour was, as noted, a bug and contrary to what was
documented and expected.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9442 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This case pops up with generic foreign key inlines after [9297]. Added tests
to handle future regressions with generic foreign key inlines in the admin.
Thanks markus and danielr for patches.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9412 bcc190cf-cafb-0310-a4f2-bffc1f526a37
nothing to send. Saves a bit of time when, for example, processing 500-error
emails with no ADMINs configured. Based on a patch from Jesse Young.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9248 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
We now raise UnicodeDecodeError for non-UTF-8 bytestrings (thanks to Daniel
Pope for diagnosing this was being swallowed by ValueError) and allow UTF-8
bytestrings as template directories.
Refs #8965.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9161 bcc190cf-cafb-0310-a4f2-bffc1f526a37
There's no guarantee about the order in which ambiguous patterns are resolved.
The solution is "don't do that" and avoid ambiguity.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9113 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is a similar situation to that fixed in r9087. We weren't merging
multiple levels of include() calls together correctly.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9099 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
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
