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
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
through all the underscore-prefixed and wrapped functions was a bit trying and
some of the names were misleading. No functional changes. Primarily, this is
just bringing the style into line with the rest of the codebase.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8604 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
times. Patch from Jeremy Carbaugh.
This is backwards incompatible in the sense that previously, if you tried to
compare timezone-aware and timezone-naive values, you got an incorrect result.
Now you get an empty string. So your previously incorrect code returns a
different incorrect result.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8579 bcc190cf-cafb-0310-a4f2-bffc1f526a37
invalid characters are correctly escaped. This avoids any chance to inject raw
HTML inside <script> tags. Thanks to Mike Wiacek for the patch and Collin Grady
for the tests.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8577 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Python beta releases. Failures there mean that incorrect code won't raise an
error, but it's otherwise harmless (correct code still runs correctly).
Fixed#7786.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8570 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Much of this work was done by Thejaswi Puthraya as part of Google's Summer of Code project; much thanks to him for the work, and to them for the program.
This is a backwards-incompatible change; see the upgrading guide in docs/ref/contrib/comments/upgrade.txt for instructions if you were using the old comments system.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8557 bcc190cf-cafb-0310-a4f2-bffc1f526a37
the timeuntil tests to fail because the pre-recorded "now" has moved on
sufficiently far from actual "now()". Fixed the one test that was failing for
me (the other timeuntil and timesince tests already have a small buffer built
in to guard against this problem).
The problem was revealed after [8535].
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8556 bcc190cf-cafb-0310-a4f2-bffc1f526a37
used with the memcache backend (which has the strongest restriction on keys).
Based on a patch from trbs.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8533 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
cases on Unix-like systems. Patch from snaury. Testing and verification on
Windows, Mac and Linux from cgrady and ramikassab.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8493 bcc190cf-cafb-0310-a4f2-bffc1f526a37
that they validate. Previous code didn't work with microseconds anyway, so this
is backwards compatible. Thanks to kevin for the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8491 bcc190cf-cafb-0310-a4f2-bffc1f526a37
presence (and incorrectness) of unique=True on ManyToManyFields. This has never
worked and generates invalid SQL. Now it's raised as an explicit error during
validation. Thanks to clamothe for the patch.
Still needs a docs change to make this clear, but that goes to the docs
refactor branch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8488 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
problem only arose on some systems, since it depends upon the order in which
the attributes are pickled. Makes reliable testing kind of tricky.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8460 bcc190cf-cafb-0310-a4f2-bffc1f526a37
when SCRIPT_NAME contains something other than '/'. Patch from jcassee.
Also fixed the middleware tests to work with this patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8456 bcc190cf-cafb-0310-a4f2-bffc1f526a37
other database backends, but the exception classes should still be the same.
This commit changes the way the tests check for specific database errors to be
more portable between implementations.
It's possible these tests will still fail if, e.g., Oracle doesn't raise
IntegrityError (but raises DatabaseError) when we except it to, but we can
cross that bridge if and when it appears.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8450 bcc190cf-cafb-0310-a4f2-bffc1f526a37
their common names/acronyms, similar to other localflavors.
Backwards incompatible if you're using these classes.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8345 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
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
aren't always equivalent. This is documented, stable behaviour, so we should
ensure it doesn't change accidentally.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8312 bcc190cf-cafb-0310-a4f2-bffc1f526a37
