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
If an update only affected an ancestor model (not the child), we were
returning 0 for the number of rows updated. This could have been
misleading if the value is used to detect an update occuring. So we now
return the rowcount from the first non-trivial query that is executed
(if any). Still a slight compromise, but better than what we had.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9966 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Allows us to reuse the same code in multiple places, avoiding new and
interesting bugs (the testing framework had a DIY version that was slightly
wrong, for example). Fixed#9833.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9936 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
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
columns when creating tables. Patch from Ian Kelly.
Columns are NULL by default, so we only need to use "NOT NULL" when we want
non-default behaviour.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9703 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
The last use of it was removed in r9641 (it's internal API) and it's been
broken since r7477, as there's no longer a maximum of one OneToOneField per
model, so anything relying on it contained subtle bugs.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9643 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
lookup in the serializable_value() method. This means that abstract
parents that are multi-table children of other models(no, really!!) now
work again.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9618 bcc190cf-cafb-0310-a4f2-bffc1f526a37
"value" for a field that is a relation to another model.
This part adds the utility method on Model that should help in general.Also
cleans up the slightly ugly mess from r8957.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9601 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Descriptors now return themselves when accessed via the class, as per standard
Python descriptors like property().
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9550 bcc190cf-cafb-0310-a4f2-bffc1f526a37
backend.
This allows Querysets to be cached for Oracle and should provide a model for
adding pickling support to other (external) database backends that need a
custom Query class.
Thanks to Justin Bronn for some assistance with this patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9272 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
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
sometimes also sharing aliases, instead of creating their own. This was
generating incorrect SQL.
No representative test for this fix yet because I haven't had time to write one
that fits in nicely with the test suite. But it works for the monstrous example
in #8790 and a bunch of other complex examples I've created locally. Will write
a test later.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8853 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
efficient than possible SQL in some odd cases (found via code inspection, not
any particular failing example).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8831 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Yes, this really is a commit that fixes an oversight in a commit that fixed an
oversight. One day I'll get it right.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8829 bcc190cf-cafb-0310-a4f2-bffc1f526a37
I can't reproduce the original error leading to #8115 and the patch. However, the only harm this change could cause is to raise more `CyclicDependency` exceptions than strictly necessary. That's better than infinite loops, at least, and it's easier to clean up in the future when we figure out the actual fix.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8807 bcc190cf-cafb-0310-a4f2-bffc1f526a37
convert it to an IntegrityError, which seems like the more natural case (and is
consistent with other backends). This makes exception handling in Django much
easier.
The solution is extensible for any other error codes we may wish to add going
forwards.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8692 bcc190cf-cafb-0310-a4f2-bffc1f526a37
fields (the latter was causing problems). This allows these values in URLs
(e.g. the admin filtering).
Not an ideal solution to the problem, but will do the job for the time being.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8691 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Backwards incompatible if you are using manually-specific primary key values
and relying on the previously documented behaviour that the new values would
always exist in the database (i.e. it would update the existing entry).
Fixed#8419.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8670 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Also comes with approximately 67% less stupidity in the table joins for
filtering on generic relations.
Fixed#5937, hopefully for good, this time.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8644 bcc190cf-cafb-0310-a4f2-bffc1f526a37
* Removed `Manipulator`, `AutomaticManipulator`, and related classes.
* Removed oldforms specific bits from model fields:
* Removed `validator_list` and `core` arguments from constructors.
* Removed the methods:
* `get_manipulator_field_names`
* `get_manipulator_field_objs`
* `get_manipulator_fields`
* `get_manipulator_new_data`
* `prepare_field_objs_and_params`
* `get_follow`
* Renamed `flatten_data` method to `value_to_string` for better alignment with its use by the serialization framework, which was the only remaining code using `flatten_data`.
* Removed oldforms methods from `django.db.models.Options` class: `get_followed_related_objects`, `get_data_holders`, `get_follow`, and `has_field_type`.
* Removed oldforms-admin specific options from `django.db.models.fields.related` classes: `num_in_admin`, `min_num_in_admin`, `max_num_in_admin`, `num_extra_on_change`, and `edit_inline`.
* Serialization framework
* `Serializer.get_string_value` now calls the model fields' renamed `value_to_string` methods.
* Removed a special-casing of `models.DateTimeField` in `core.serializers.base.Serializer.get_string_value` that's handled by `django.db.models.fields.DateTimeField.value_to_string`.
* Removed `django.core.validators`:
* Moved `ValidationError` exception to `django.core.exceptions`.
* For the couple places that were using validators, brought over the necessary code to maintain the same functionality.
* Introduced a SlugField form field for validation and to compliment the SlugField model field (refs #8040).
* Removed an oldforms-style model creation hack (refs #2160).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8616 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This isn't a complete solution to this class of problem, but it will do for
1.0, which only has generic relations as a multicolumn type. A more general
multicolumn solution will be available after that release.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8608 bcc190cf-cafb-0310-a4f2-bffc1f526a37
instances. We weren't skipping the correct output columns before processing
subsequent existing related instances. Thanks to mrmachine for the test case.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8598 bcc190cf-cafb-0310-a4f2-bffc1f526a37
used in "month" and "day" filters on date/datetime fields. Without this commit,
SQLite behaved inconsistently after [8494].
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8526 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This restores filtering on dates in the admin, for example. Thanks to akfarrell
and a small team of workers at the Portland Sprint.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8494 bcc190cf-cafb-0310-a4f2-bffc1f526a37
fields no longer creates duplicate copies of the join table(s). Basically, this
means filters on the join table (for ManyToManyField(through=...)) and complex
filters in the normal (non-through) case don't produce incorrect or duplicate
results.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8472 bcc190cf-cafb-0310-a4f2-bffc1f526a37
environment doesn't support os.listdir(), we crashed whilst trying to construct
the friendly error message. This was not so friendly.
This patch handles that case (which occurs in real life in Google App Engine).
Patch from Guido van Rossum.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8424 bcc190cf-cafb-0310-a4f2-bffc1f526a37
code. As pointed out in the ticket, Python still lets you raise all sorts of
odd things as exceptions (e.g. strings), so even though they're bad form, we
should still handle them. We do that cleanly now. Thanks to jim-django@dsdd.org
for the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8419 bcc190cf-cafb-0310-a4f2-bffc1f526a37
transaction (after another exception in the code), make sure the original
exception is reported, rather than the rollback-generated one. The latter is
almost certainly a consequence of the former. Patch from Karen Tracey.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8411 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This effectively reverses the change in [7798]. It was proving too difficult to
successfully manage all the side effects here and provide a satisfactory
solution for everybody. Many thanks to arne, Martin von Löwis and, particular,
Karen Tracey, for doing a lot of research and proto-patches here to establish what was possible and practical.
This is backwards incompatible if you were relying on the behaviour after
[7798]. The docs have been updated to indicate the solution.
Refs #2170, #7789, #8102.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8319 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Fixed#7402.
Also made savepoint handling easier to use when wrapped around calls that might
commit a transaction. This is tested by the get_or_create tests.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8315 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is a no-op for most databases. Only necessary on PostgreSQL so that we can
do things which will possibly intentionally raise an IntegrityError and not
have to rollback the entire transaction. Not supported for PostgreSQL versions
prior to 8.0, so should be used sparingly in internal Django code.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8314 bcc190cf-cafb-0310-a4f2-bffc1f526a37
* Support for representing files as strings was removed. Use `django.core.files.base.ContentFile` instead.
* Support for representing uploaded files as dictionaries was removed. Use `django.core.files.uploadedfile.SimpleUploadedFile` instead.
* The `filename`, `file_name`, `file_size`, and `chuck` properties of `UploadedFile` were removed. Use the `name`, `name`, `size`, and `chunks` properties instead, respectively.
* The `get_FIELD_filename`, `get_FIELD_url`, `get_FIELD_size`, and `save_FIELD_file` methods for Models with `FileField` fields were removed. Instead, use the `path`, `url`, and `size` attributes and `save` method on the field itself, respectively.
* The `get_FIELD_width` and `get_FIELD_height` methods for Models with `ImageField` fields were removed. Use the `width` and `height` attributes on the field itself instead.
* The dispatcher `connect`, `disconnect`, `send`, and `sendExact` functions were removed. Use the signal object's own `connect`, `disconnect`, `send`, and `send` methods instead, respectively.
* The `form_for_model` and `form_for_instance` functions were removed. Use a `ModelForm` subclass instead.
* Support for importing `django.newforms` was removed. Use `django.forms` instead.
* Support for importing `django.utils.images` was removed. Use `django.core.files.images` instead.
* Support for the `follow` argument in the `create_object` and `update_object` generic views was removed. Use the `django.forms` package and the new `form_class` argument instead.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8291 bcc190cf-cafb-0310-a4f2-bffc1f526a37
searching within a field column (e.g. "like", "contains", etc). Required for
PostgreSQL 8.3. Thanks to Dan Watson for the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8242 bcc190cf-cafb-0310-a4f2-bffc1f526a37
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
Malcolm Tredinnick
Ian Kelly
Karen Tracey
Russell Keith-Magee
Matt Boersma
Jacob Kaplan-Moss
Luke Plant
Adrian Holovaty
Brian Rosner
Gary Wilson Jr