Updated docs to reflect the change, and the fact that using the
two separate middleware is preferred to using the combined one.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10094 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
These features look similar, but they're not identical. They can't be merged
into one (without requiring at least two Meta parameters anyway), so we've made
them have APIs that match their natural use-cases most easily.
Anyway, the documentation explains both the details and gives some simple to
follow rules.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10089 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Large portions of this are needed for #5420, so I implemented it fully.
Thanks to Ryan Kelly for an initial patch to get this started.
Refs #5420.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10083 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Looks like we have to use the same format specifiers in both singular and
plural forms of a message or the PO file cannot be compiled to MO format. This
commit changes one place in admin that was using different specifiers.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10081 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Affects the postgresql_psycopg2 backend only. We now don't use the
"RETURNING" syntax in SQL INSERT statements unless it's required by the
autocommit behaviour. This fixes an edge-case that could cause crashes
with earlier PostgreSQL versions, but the broader problem remains to be
fixed (which is #10509).
Fixed#10467. Refs #10509.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10065 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is for Manager subclasses that are default managers, but only
sometimes. The general rule is: "don't use it." If you really need it,
read the instructions.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10057 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
In order to report more comphrehensible tracebacks, remove the super()
constructor call, since passing args to object.__init__ ends badly. So some
subclassing possibilities are now removed, but it's the "dummy" backend, so
we can make some compromises.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10042 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This only shows up in for reverse() (not forwards resolving), since that
path uses a globally shared resolver object. Based on a patch from
Travis Terry.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10037 bcc190cf-cafb-0310-a4f2-bffc1f526a37
I introduced a bad regression in r10029, forgetting to check that some
syntax was supported. For now, you can't use autocommit=True with 8.1
and earlier (it's still available for later versions). I'll fix the
broader issue later and re-enable it for those versions, but I want to
get the SQL regression for the default path out of the code right now.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10035 bcc190cf-cafb-0310-a4f2-bffc1f526a37
There was a bug in the way we were reading the DATABASE_OPTIONS setting
and a lot of essentially duplicated code. This is neater.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10033 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Ensure to read the documentation before blindly enabling this: requires some
code audits first, but might well be worth it for busy sites.
Thanks to nicferrier, iamseb and Richard Davies for help with this patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10029 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is backwards-compatible but will likely break third-party database backends. Specific API changes are:
* BaseDatabaseWrapper.__init__() now takes a settings_dict instead of a settings module. It's called settings_dict to disambiguate, and for easy grepability. This should be a dictionary containing DATABASE_NAME, etc.
* BaseDatabaseWrapper has a settings_dict attribute instead of an options attribute. BaseDatabaseWrapper.options is now BaseDatabaseWrapper['DATABASE_OPTIONS']
* BaseDatabaseWrapper._cursor() no longer takes a settings argument.
* BaseDatabaseClient.__init__() now takes a connection argument (a DatabaseWrapper instance) instead of no arguments.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10026 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Luke Plant
Malcolm Tredinnick
Jacob Kaplan-Moss
Russell Keith-Magee
Jarek Zgoda
Gary Wilson Jr
Adrian Holovaty
Ian Kelly