Summary

Add a serialization layer for signature and Python data representations.

Review Request #12012 — Created Jan. 26, 2022 and submitted Jan. 28, 2022, 6:23 p.m.

Information

Owner

chipx86

Repository

Django Evolution

Branch

release-2.x

Bugs

Depends On

Reviewers

Groups

django-evolution

People

Description

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.

Testing Done

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

Commits

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

Summary

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

Issues

Description	From	Last Updated
F401 'types' imported but unused	reviewbot	Jan. 27, 2022, 12:02 a.m.
E303 too many blank lines (3)	reviewbot	Jan. 27, 2022, 12:02 a.m.

flake8 failed.

JSHint passed.

flake8

django_evolution/serialization.py (Diff revision 1)
The issue has been resolved. Show all issues
```
F401 'types' imported but unused
```
django_evolution/serialization.py (Diff revision 1)
The issue has been resolved. Show all issues
```
E303 too many blank lines (3)
```

Change Summary:


Fixed some blank lines and unused imports.
Added the missing unit tests file.
Added serialization.py to the API docs.

Commits:

	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.	3f5ef166fb59116b762874b0bd52c0b9dceb7b6d
	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

Diff:

Revision 2 (+2878 -160)

Show changes

	django_evolution/mutations.py
	django_evolution/serialization.py
	django_evolution/signature.py
	django_evolution/tests/base_test_case.py
	django_evolution/tests/test_serialization.py
	django_evolution/tests/test_signature.py
	docs/coderef/index.rst

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Status:: Completed
Change Summary:: Pushed to release-2.x (4a2a8d8)