* Moved dimension field update logic out of `ImageFileDescriptor.__set__` and into its own method on `ImageField`.
* New `ImageField.update_dimension_fields` method is attached to model instance's `post_init` signal so that:
* Dimension fields are set when defined before the ImageField.
* Dimension fields are set when the field is assigned in the model constructor (fixes#11196), but only if the dimension fields don't already have values, so we avoid updating the dimensions every time an object is loaded from the database (fixes#11084).
* Clear dimension fields when the ImageField is set to None, which also causes dimension fields to be cleared when `ImageFieldFile.delete()` is used.
* Added many more tests for ImageField that test edge cases we weren't testing before, and moved the ImageField tests out of `file_storage` and into their own module within `model_fields`.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10858 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This bug actually exposed a related handful of inconsistancies in the underlying file handling and wraping, so a few related changes are in here as well:
* Dimensions are also now calculated the moment the image is assigned to the field instead of upon save.
* The base `File` object now when possible delegates its closed attribute down to the os-level file it wrapps.
* In-memory files' `close()` now is a no-op. Without this certain APIs that should be able to handle in-memory files were failing.
* Accessing `FieldFile.closed` used to open the file. That's silly, and it doesn't any more.
* Some over-eager error handling was squishing some errors that would normally be raised. One unit test was incorrectly depending on this behavior, so the test was removed.
Thanks to Armin Ronacher for much of this work.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10737 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This enables querysets with an extra clause to be used in an __in filter; as a side effect, it also means that as_sql() now returns the correct result for any query with an extra clause.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10648 bcc190cf-cafb-0310-a4f2-bffc1f526a37
We need to know the number of rows that are matched by an UPDATE query,
not just the number of rows that are changed. In the relatively unlikely
event that somebody was using Django's cursor proxy and relying on the
previous behaviour, well, that isn't the case any longer. We need to
this version.
Thanks to Daniel Tang for pointing out the solution here.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10532 bcc190cf-cafb-0310-a4f2-bffc1f526a37
We now pass numbers used in data queries as actualy numbers (integers) to the
database backends, rather than string forms. This is easier for some of the
less flexible backeds.
Based on a patch from Leo Soto and Ramiro Morales.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10530 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Loading related models when some fields were deferred was resulting in
incorrect offsets being used into the results row, causing the wrong data to be
assigned to attributes.
Refs #10710. This fixes the first of two bugs reported there.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10383 bcc190cf-cafb-0310-a4f2-bffc1f526a37
The original implementation had a few silly bugs in it that meant that data was
not being used only on the instance of the class that it was appropriate for
(one of the traps when using class-level things). No more!
Thanks to Justin Bronn and Alex Gaynor for the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10382 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Using select_related(...) across a nullable relation to a multi-table
model inheritance situation no longer excludes results. Thanks to AdamG
for a test demonstrating part of the problem.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10136 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
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
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
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
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
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
This allows a model to be defined which is not subject to database table
creation and removal. Useful for models that sit over existing tables or
database views.
Thanks to Alexander Myodov, Wolfgang Kriesing and Ryan Kelly for the bulk of
this patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10008 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This removes a long-standing FIXME in the update() handling and allows for
greater flexibility in the values passed in. In particular, it brings updates
into line with saves for django.contrib.gis fields, so fixed#10411.
Thanks to Justin Bronn and Russell Keith-Magee for help with this patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10003 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
This was always not working reliably (model initialization and serialization
were two of the problems). Now, it's an explicit error. Also, documented.
Fixed#10252.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9974 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
Russell Keith-Magee
Gary Wilson Jr
Matt Boersma
Jacob Kaplan-Moss
Malcolm Tredinnick
Ian Kelly
Karen Tracey
Justin Bronn
Joseph Kocherhans
Adrian Holovaty