loads has no way to tell if it should provide text or bytes to the
serializer; bytes are more reasonnable for a serialized representation,
and are the only option for pickled data.
dumps can perform conversions on the value it receives from the
serializer; but for consistency it seems better to require bytes too.
The current code would cause an exception when loading pickled session
data. See next commit.
Also fixed a bug when checking for compressed data.
There was a potential data-loss issue involved -- when clearing
instance's m2m assignments it was possible some other instance's
m2m data was deleted instead.
This commit also improved None handling for to_field cases.
* Prevented stale session files from being loaded
* Added removal of stale session files in django-admin.py clearsessions
Thanks ej for the report, crodjer and Elvard for their inputs.
These tests are expected to fail for the file session backend because it
doesn't handle expiry properly. They didn't because of an error in the
test setup sequence.
Refs #19200, #18194.
This change allows for cleaner tests: we can test the exact output.
Refs #18194: this change makes it possible to compute session expiry
dates at times other than when the session is saved.
Fixed#18458: the existence of the `modification` kwarg implies that you
must pass it to get_expiry_age/date if you call these functions outside
of a short request - response cycle (the intended use case).
The Query.select and Query.select_fields were collapsed into one list
because the attributes had to be always in sync. Now that they are in
one attribute it is impossible to edit them out of sync.
Similar collapse was done for Query.related_select_cols and
Query.related_select_fields.
Since http://bugs.python.org/issue2193 has been resolved in favour of
the colon in cookie names, we need to test invalid cookie removal using
a different character. "@" is still considered invalid by all sources.
There was a bug introduced in #18676 which caused fast-path deletes
implemented as "DELETE WHERE pk IN <subquery>" to fail if the SELECT
clause contained additional stuff (for example extra() and annotate()).
Thanks to Trac alias pressureman for spotting this regression.
This case was originally designed to handle Exception's which didn't gracefully support coercing themselves to unicode. However, because it lives in the `else` case of `if hasattr(s, '__unicode__'):` we can be sure it's no longer reachable in djanog anymore, because since Python 2.5 exception has subclassed object, which means Exception objects always have an __unicode__ method.