Currently when serializing a value with a reference to an object, the full object identifier will be serialized, as is returned by corto_fullpath. In many cases however that is not correct behavior, since objects might be mounted under different locations in different stores. Therefore, serializers should serialize object references relative to the point where their serialized data is mounted.
Since serializers themselves are not aware of where the entities that are performing the serialization (mounts, subscribers, select) are serializing from, the serializer framework should generically support serializing from a relative path.
This does however mean that if a JSON mount communicates with a JSON subscriber, the JSON is not automatically compatible. A quick check on whether a type contains references (using the type->flags member) can determine whether the data needs to be re-serialized or whether it can be copied. If the source and destination use the same relative path, the same serialized data can be used.
This applies to both serializers and deserializers.
This will introduce a breaking change in the serializer API. To prevent breaking changes in the future, a more flexible mechanism should be used to pass down information into serializers.
Currently when serializing a value with a reference to an object, the full object identifier will be serialized, as is returned by
corto_fullpath. In many cases however that is not correct behavior, since objects might be mounted under different locations in different stores. Therefore, serializers should serialize object references relative to the point where their serialized data is mounted.Since serializers themselves are not aware of where the entities that are performing the serialization (mounts, subscribers, select) are serializing from, the serializer framework should generically support serializing from a relative path.
This does however mean that if a JSON mount communicates with a JSON subscriber, the JSON is not automatically compatible. A quick check on whether a type contains references (using the
type->flagsmember) can determine whether the data needs to be re-serialized or whether it can be copied. If the source and destination use the same relative path, the same serialized data can be used.This applies to both serializers and deserializers.
This will introduce a breaking change in the serializer API. To prevent breaking changes in the future, a more flexible mechanism should be used to pass down information into serializers.