Skip to content

Releases: grofit/persistity

A Major Overhaul

24 Mar 08:17
Compare
Choose a tag to compare

We have done a large overhaul of the underlying flow of things and now have far more configurable and customizable pipelines out the box.

Read the docs for more info but now most pipelines are more like simple streams.

Minor Fixes & Pipeline/Deserialization Changes

11 Apr 11:29
Compare
Choose a tag to compare

Minor Fixes

There was a missing interface from the binary serializer which was missing the interface, that has now been fixed.

Pipeline Changes

There is a breaking change on pipelines where you can send a state object with the data, this can be useful for custom pipelines where you need to provide some state to indicate how the endpoint should handle the data, i.e if you needed to provide the id of the object along with the serialized data. This is more a placeholder for now but can be used for pipelines where you want to explicitly do something based upon both data and the state/context of that data.

Deserialization Changes

This is a non breaking change but there is now the introduction of the DeserializeInto method which allows you to provide an existing instance that you wish to use as the container for deserialized data, this allows you to keep existing references in code while updating models with newer values.

Serializer Rewrite and Dynamic Type Support

04 Apr 10:59
Compare
Choose a tag to compare

Serialization Rewrite

So this version streamlines the serializers by having a GenericSerializer and GenericDeserializer which expresses the default steps involved in serialization, this reduces the implementation size of each actual serializer (and deserializer) by 50-75%. You can still make your own bespoke versions by implementing ISerializer directly but this makes it easier to maintain the core logic and only overwrite what changes. It was noticed when adding dynamic type support that a good 50% of the code was the same in all classes so new features were constantly needing multiple implementations which were identical but needed internal state so couldnt be expressed as extensions, anyway that sums up the serialization changes (which wont really impact consumers).


Dynamic Type Support

This is a big one, so by default now it will write out type meta data if the property type is not descriptive enough for instantiation at deserialization time. So for example if you have a property public object SomeValue {get;set;} the type object is not descriptive enough to know from the type mapping alone what the type should be when deserializing. So to support these use cases it will output type data automatically for these scenarios and you can hint to the type mapper to do this with attributes (there is a new doc in the docs folder detailing this).

Just to be clear this ONLY happens if the type is not concrete enough for a property, if you have a well defined POCO or primitive type it will not output type information, so this pragmatic approach will hopefully allow data sizes to remain low for the most part.


Json Dependency

Due to the streamlining of serialization the way we handled JSON needed to change as it was working back to front compared to the other serializers, so we have adopted JSON.NET for the JSON serialization, however if you do not need JSON support your can ignore this dependency and remove the json serializers from your project which should work fine.

Breaking Changes Ahoy!

27 Mar 15:02
Compare
Choose a tag to compare

Ok so this release breaks a lot, ISerializers now replace the previous notion of ITransformer, which has now been re-purposed into a real transformation style interface which maps one statically typed model to another. There is also now some support from transforming within the pipelines as well as making the data passed around within the pipeline a DataObject rather than byte[] which makes it easier to change things going forward as well as being able to work as byte array or string depending on scenario.

The docs have been updated to reflect all this, so hopefully it wont cause too much of a headache for consumers.

Added KnownTypes/Primitives

23 Mar 12:43
Compare
Choose a tag to compare

This release adds the notion of KnownTypes as well as KnownPrimitives to the TypeMapper as well as the Serializers, as well as a few other changes.

Known Types / Primitives

So there is now an ITypeHandler interface which allows you to implement your own serialization logic for custom types, this should ideally work in tandem with the TypeMapper which can flag types as a primitive, so for example if you were using uniRx and you had a ReactiveProperty by default it would treat it as a nested object and try to find any properties within that are flagged with [PersistData] which it would not find any. So this allows you to tell the mapping process that any ReactiveProperty types should be seen as primitives and not nested objects, then in the serialization phase tell it that you really only want to serialize the Value field, so this way you can work with 3rd party models and complex objects and serialize them in a custom way if you want to optimise your serialization or handle unsupported use-cases from out the box.

Refactors

There have also been some refactors in this release such as moving the Exceptions to their own namespace, adding an ITypeMapper interface and other type mapper implementations to the mix. There are also updates to the docs to reflect these changes.

Initial Version

23 Mar 08:56
Compare
Choose a tag to compare

This is the initial version which contains the basic framework, which will hopefully get added to going forward, please check the docs and join the gitter room (shared with EcsRx and BindingsRx) if you have any questions.