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
Malcolm Tredinnick
Gary Wilson Jr
Jacob Kaplan-Moss
Russell Keith-Magee
Brian Rosner