Add a serialization layer for signature and Python data representations.

Review Request #12012 — Created Jan. 26, 2022 and submitted

Information

Django Evolution
release-2.x

Reviewers

We have two places in Django Evolution where we need to create
representations of data (everything from primitives to class references
to object instances): The stored database signature, and the evolution
hints.

We also need to take signature data and turn it back into usable
objects.

Previously, this was being done by some utility functions within the
mutation and signature layers, but with growing complexity in database
options for modern versions of Django, a new approach was needed.

This change introduces centralized serialization code for this. There
are serialization classes registered for all types of content that we'd
want to represent, which handle serializing to signatures, serializing
to Python code, and deserializing from signatures.

The three functions provided are serialize_to_python,
serialize_to_signature, and deserialize_from_signature.

Behind these is a couple of registries mapping types to the
serialization classes responsible for the implementations.

Django "deconstruction" support is available, which is how Django
objects serialize themselves. There's support for this, and explicit
support for working around changes they've made to this for Q query
objects. We now support all variations of this format.

Unit tests pass on all supported versions of Python and Django.

Summary ID
Add a serialization layer for signature and Python data representations.
We have two places in Django Evolution where we need to create representations of data (everything from primitives to class references to object instances): The stored database signature, and the evolution hints. We also need to take signature data and turn it back into usable objects. Previously, this was being done by some utility functions within the mutation and signature layers, but with growing complexity in database options for modern versions of Django, a new approach was needed. This change introduces centralized serialization code for this. There are serialization classes registered for all types of content that we'd want to represent, which handle serializing to signatures, serializing to Python code, and deserializing from signatures. The three functions provided are `serialize_to_python`, `serialize_to_signature`, and `deserialize_from_signature`. Behind these is a couple of registries mapping types to the serialization classes responsible for the implementations. Django "deconstruction" support is available, which is how Django objects serialize themselves. There's support for this, and explicit support for working around changes they've made to this for `Q` query objects. We now support all variations of this format.
19ed910d9a87188d978004d386311686db7f0b37
Description From Last Updated

F401 'types' imported but unused

reviewbotreviewbot

E303 too many blank lines (3)

reviewbotreviewbot
Checks run (1 failed, 1 succeeded)
flake8 failed.
JSHint passed.

flake8

chipx86
david
  1. Ship It!
  2. 
      
chipx86
Review request changed
Status:
Completed
Change Summary:
Pushed to release-2.x (4a2a8d8)