Though some attempts and backwards-compatibility were made, speed trumped compatibility. Thus, as usual, check BackwardsIncompatibleChanges for the complete list of backwards-incompatible changes.
Thanks to Jeremy Dunck and Keith Busell for the bulk of the work; some ideas from Brian Herring's previous work (refs #4561) were incorporated.
Documentation is, sigh, still forthcoming.
Fixes#6814 and #3951 (with the new dispatch_uid argument to connect).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8223 bcc190cf-cafb-0310-a4f2-bffc1f526a37
* Model init no longer performs a database query to refetch the related objects it is passed.
* Model init now caches unsaved related objects correctly, too. (Previously, accessing the field would raise `DoesNotExist` error for `null=False` fields.)
* Added tests for assigning `None` to `null=True` `ForeignKey` fields (refs #6886).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8185 bcc190cf-cafb-0310-a4f2-bffc1f526a37
At the same time, checked all other cases of db_prep_value() to ensure they
aren't making the same mistake.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8143 bcc190cf-cafb-0310-a4f2-bffc1f526a37
loading/saving interactions with the databases into django.db.backend. This
helps external db backend writers and removes a bunch of database-specific
if-tests in django.db.models.fields.
Great work from Leo Soto.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8131 bcc190cf-cafb-0310-a4f2-bffc1f526a37
the prequisites are correctly initialised prior to using them. Only affects
Oracle and other db backends requiring resolve_columns() (e.g. MS SQL?)
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8112 bcc190cf-cafb-0310-a4f2-bffc1f526a37
match nothing). This allows for some more straightforward code in the admin
interface.
Fixed#7488 (all the debugging there was done by Brian Rosner, who narrowed it
down to the item in this patch).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8061 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Based on a patch from Justin Bronn.
The test in this patch most likely breaks on Oracle. That's another issue.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8053 bcc190cf-cafb-0310-a4f2-bffc1f526a37
not required, by default), set the default properly in the constructor.
This code can be simplified when/if we resolve the
BooleanField/NullBooleanField overlap, but the current stuff is backwards
compatible. This would previously cause SQL errors on PostgreSQL and
interesting failures in subtle ways on MySQL and SQLite.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8050 bcc190cf-cafb-0310-a4f2-bffc1f526a37
It turns out that we need to treat filename creation/display (in
particular, the upload_to path) differently depending upon whether the value is
out of the database or provided by other code and there's no reliable way to
determine that at the moment (although some later proposed changes might alter
that). So calling get_FIELD_filename on an unsaved model with a changed file
attribute will not necessarily return the same result as after the save().
Refs #5619. Fixed#7843.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7998 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is a backward incompatible change. The admin contrib app has been
refactored. The newforms module has several improvements including FormSets
and Media definitions.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7967 bcc190cf-cafb-0310-a4f2-bffc1f526a37
newforms-admin merges (to handle changes in [7790]).
This code becomes irrelevant in a non-oldforms world, so even if it's not quite
correct, it will do for now. Based on a patch from puyb@puyb.net and Karen
Tracey.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7882 bcc190cf-cafb-0310-a4f2-bffc1f526a37
* The API now more closely matches a proper file API. This unfortunately means a few backwards-incompatible renamings; see BackwardsIncompatibleChanges. This refs #7593.
* While we were at it, renamed chunk() to chunks() to clarify that it's an iterator.
* Temporary uploaded files now property use the tempfile library behind the scenes which should ensure better cleanup of tempfiles (refs #7593 again).
Thanks to Mike Axiak for the bulk of this patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7859 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This removes some of the leaky abstraction problems (lifting WhereNode
internals into the Query class) from that commit and makes it possible for
extensions to WhereNode to have access to the field instances. It's also
backwards-compatible with pre-[7773] code, which is also better.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7835 bcc190cf-cafb-0310-a4f2-bffc1f526a37
A description of the new features can be found in the new [http://www.djangoproject.com/documentation/upload_handing/ upload handling documentation]; the executive summary is that Django will now happily handle uploads of large files without issues.
This changes the representation of uploaded files from dictionaries to bona fide objects; see BackwardsIncompatibleChanges for details.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7814 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This avoids any use of "pk is not NULL" fragment, which behave inconsistently
in MySQL. Thanks to Russell Keith-Magee for diagnosing the problem and
suggesting the easy fix.
Refs #7076.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7812 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is a backwards incompatible change if you were relying on 'exact' being
case-insensitive. For that, you should be using 'iexact'.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7798 bcc190cf-cafb-0310-a4f2-bffc1f526a37
OrderingField was added in the magic-removal branch to support something that
never ultimately materialised, but it wasn't removed. So this is
backwards-incompatible if you're using this field that has no purpose, I guess.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7794 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Also added a section to the documentation to indicate why it's probably not a
good idea to rely on this feature for complex stuff. Garbage in, garbage out
applies even to Django code.
Thanks to erik for the test case for this one.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7791 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This patch simplifies a bunch of code for all backends and removes some
duplicate index creation for MySQL, in particular (versions 4.x and later).
Patch from Nis Jørgensen.
Fixed#5671, #5680, #7170, #7186.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7790 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Patch from mturtle@gmail.com. The remaining uses of "%s__pk" in
fields/related.py all look safe, since they are for many-to-many fields, which
doesn't take "to_field" as a parameter.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7785 bcc190cf-cafb-0310-a4f2-bffc1f526a37
When model inheritance is used, the parent objects should be deleted as part of
the delete() call on the child.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7784 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Some fields need to know the right db_table setting in their own
contribute_to_class(), so waiting until Options._prepare() is a little
inconvenient. This is a deep-internals change. No effect on external code.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7777 bcc190cf-cafb-0310-a4f2-bffc1f526a37
We no longer store any reference to Django field instances or models in the
Where node. This should improve cloning speed, fix some pickling difficulties,
reduce memory usage and remove some infinite loop possibilities in odd cases.
Slightly backwards incompatible if you're writing custom filters. See the
BackwardsIncompatibleChanges wiki page for details.
Fixed#7128, #7204, #7506.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7773 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is pretty much internal-use-only code, so doesn't affect public API at
all, but it's nice to be able to handle things properly in any case. Patch from
emulbreh.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7766 bcc190cf-cafb-0310-a4f2-bffc1f526a37
These types of relations don't have reverse accessor names, so that name can be
used by a normal field on the model. Fixed#7107.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7764 bcc190cf-cafb-0310-a4f2-bffc1f526a37
so that the ordering doesn't accidentally restrict the result set.
(Ironically, one existing test actually showed this problem, but I was too
dumb to notice the result was incorrect.)
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7761 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Field.db_type().
This fixes a problem with using reserved words for field names in Oracle. Only
affects Oracle at the moment, but the same changes could easily be used by
other backends if they are required (requires changing creation.py, only).
This commit also reverts [7501] so that if the fix doesn't work, it will show
up in the tests (and if it does work, the tests will prevent us from breaking
it again).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7743 bcc190cf-cafb-0310-a4f2-bffc1f526a37
It was causing too many inconvenient and unintended problems when merging
legitimate subclasses (e.g. with geo-django classes). There's still a hook
there that we use when merging ValueQuerySets, but if you try to merge two
disparate QuerySets and it breaks all that happens is you get to keep both
pieces. We're no longer penalising the useful usages just for the people who
aren't concentrating.
Fixed#7113.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7742 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Avoids joining with the wrong tables when connecting select_related() tables to
the main query. This also leads to slightly more efficient (meaning less tables
are joined) SQL queries in some other cases, too. Some unnecessary tables are
now trimmed that were not previously.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7741 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Previously, if we were querying across a nullable join and then a non-nullable
one, the second join would not be a LEFT OUTER join, which would exclude
certain valid results from the result set.
This is the same problem as [7597] but for values() field specifications, so
this covers the second case where Django adds extra stuff to the select-clause.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7740 bcc190cf-cafb-0310-a4f2-bffc1f526a37
* Serializers were including all superclass fields in their output. Now only local fields are included.
* Implicit OneToOne primary keys were not correctly added to the metamodel, so they were always marked to be serialized, even though they were primary
* Model saving was too aggressive about creating new parent class instances during deserialization. Raw save on a model now skips saving of the parent class.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7600 bcc190cf-cafb-0310-a4f2-bffc1f526a37
* Raise a ValueError if you try to assign the wrong type of object.
* Raise a ValueError if you try to assign None to a field not specified with null=True.
* Cache the set value at set time instead of just at lookup time.
This is a slightly backwards-incompatible change; see BackwardsIncompatibleChanges for more details.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7574 bcc190cf-cafb-0310-a4f2-bffc1f526a37
database level. Also worked around the fact that MySQL (and maybe other
backends we don't know about) cannot select from the table they're updating.
Fixed#7095.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7496 bcc190cf-cafb-0310-a4f2-bffc1f526a37
marked as erroneous. It's just more dangerous and risky, not forbidden. This
commit restores backwards compatibility there.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7490 bcc190cf-cafb-0310-a4f2-bffc1f526a37
It has not been maintained, contains bugs, and improved versions are available
externally(e.g. django-mssql and django-pyodbc at Google code).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7364 bcc190cf-cafb-0310-a4f2-bffc1f526a37
database backends differently now. Which meant the MySQLdb version check was
being swallowed. Changed the exception type to ensure this is percolated
correctly. Patch from Ramiro Morales.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7358 bcc190cf-cafb-0310-a4f2-bffc1f526a37
(via a callable). Also updates the documentation of the "default" attribute to
indicate a callable can be used. Thanks, Philipe Raoult.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7331 bcc190cf-cafb-0310-a4f2-bffc1f526a37
going to be using the same database column type. Made that properly
inheritable (previously it was using the class name), at the cost of a little
more verboseness.
This is very slightly backwards incompatible (for subclasses of existing fields
that were relying on the old default).
Fixed#6556.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7133 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Malcolm Tredinnick
Jacob Kaplan-Moss
Gary Wilson Jr
Russell Keith-Magee
Matt Boersma
Adrian Holovaty
Brian Rosner
Ian Kelly
Luke Plant