Opened 6 years ago
Closed 6 years ago
#29550 closed Cleanup/optimization (fixed)
Ease overriding pickling protocol in session serialization and cache backends
Reported by: | Simon Charette | Owned by: | Simon Charette |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
During the process of porting Django projects from Python versions to newer ones a common late stage step is to turn some instances of a cluster into canaries running the latest version. While state sharing between canaries and the rest of the fleet should be avoided it's not always possible to completely isolate them. For example, starting from a cold isolated cache might be impractical at a certain scale.
This is particularly problematic when dealing with pickled data because Django always uses the latest protocol (through the pickle.HIGHEST_PROTOCOL
constant) which prevent the data from being unpickled on instances that don't have access. For example, if some data is pickled on Python 3.4 canary where pickle.HIGHEST_PROTOCOL == 4
it won't be pickleable on the rest of the Python 3.3 servers sharing this global state.
Django should make it easier to override the pickling protocol used within methods and functions to allow users to temporarily _freeze_ the protocol used during the transition period.
Change History (3)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
Component: | Uncategorized → Core (Other) |
---|---|
Summary: | Usages of pickling should easen protocol overriding → Ease overriding pickling protocol in session serialization and cache backends |
Triage Stage: | Unreviewed → Ready for checkin |
PR