NOTE: This change is backwards incompatible for some users.
If you are using a 32-bit platform, you will observe no differences as a
result of this change. However, users on 64-bit platforms may experience
some problems using the `reset` management command.
Prior to this change, 64-bit platforms would generate a 64-bit, 16 character
digest in the constraint name; for example:
ALTER TABLE `myapp_sometable` ADD CONSTRAINT `object_id_refs_id_5e8f10c132091d1e` FOREIGN KEY ...
Following this change, all platforms, regardless of word size, will
generate a 32-bit, 8 character digest in the constraint name; for example:
ALTER TABLE `myapp_sometable` ADD CONSTRAINT `object_id_refs_id_32091d1e` FOREIGN KEY ...
As a result of this change, you will not be able to use the `reset`
management command on any table created with 64-bit constraints. This
is because the the new generated name will not match the historically
generated name; as a result, the SQL constructed by the `reset` command
will be invalid.
If you need to reset an application that was created with 64-bit
constraints, you will need to manually drop the old constraint prior
to invoking `reset`.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10966 bcc190cf-cafb-0310-a4f2-bffc1f526a37
* 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