The serializer_id attribute

[damskii9992]

Context

When serializing objects which reference other objects, such as with dependencies in #121, it is necessary to be able to save this reference across sessions.

The unique_name identification system provides unique id's for objects, but due to them being simple, user-customizable, and auto-generated with a simple increasing integer, they fail to be unique across multiple sessions which results in clashes or inconsistencies upon de-serialization.

The serialization-only id

To solve this issue we have implemented a transient ID meant only for serialization/de-serialization.

The serializer_id property is name-mangled (i.e. it is called __serializer_id) to avoid accidental overwrites, and it is only created and assigned to an object when it gets references by another object (such as by being used in a dependent Parameter).

Upon serialization of objects, the serializer_id is added to the serialized objects dictionary and any references to the object, including references by unique_names, are replaced with this serializer_id to ensure reliable reconstruction of this reference upon de-serialization.

When de-serializing objects, the references are initially ignored since objects can be de-serialized in any order and it is crucial for the referenced object to exist before attempting to re-create the reference.

Once all objects have been de-serialized (they now hold their serializer_id attribute if it existed in their serialized dictionary), all the references can be re-created by running the corresponding reference resolver (dependency_resolver for dependent Parameters).
This reference resolver will go through an object, look up its references by their serializer_id by going through all the objects in the global_objects map, replace this reference with a regular object reference or unique_name reference, and then delete the serializer_id on those objects, hence why the serializer_id is called "transient".

Potential issues or pitfalls

The reference resolver can only be run once. Since it deletes serializer_ids after using them, any subsequent objects with references with these serializer_ids, de-serialized after the reference resolver has been run, won't be able to re-create their references since this serializer_id no longer exists. To avoid this pitfall, the reference resolver should only be run after all object have been de-serialized.

Link to the ADR suggestion:
#164