-
-
Notifications
You must be signed in to change notification settings - Fork 53
FAQ
Use ShouldSerializeMember in the config (SerializerConfig)
Yes, in the most efficient way: Instead of having Ceras do thousands of "Stream.Write" calls, it first serializes everything to a buffer (that can also be re-used), and then the whole buffer can be written in one go.
...but what if my objects / object-graphs are too big? Or what if I want to serialize smaller parts for lower latency?
Not a problem at all: check out IExternalRootObject in the tutorial.
While MessagePack-CSharp is an excellent library, it is still bound to the 'MsgPack' format, and thus its inefficiencies. Complex type hierarchies and references are a big problem. While the MessagePack-CSharp library managed to allivate some problems with the msgpack-standard, there are still many problems for real-world scenarios. One of which is the need to annotate every object and field with an ID-key, having to manually setup attributes in your hierarchy everywhere, making sure nothing collides... it quickly gets out of hand. Ceras fixes all those things (and more) completely.
I'm forced to work with unknown types and can't provide any (at least some) types to KnownTypes, what are my options?
You can still get some massive space-savings by shortening the namespaces.
Using a custom TypeBinder that's very easy. For example your TypeBinder could just replace the first 3 parts in MyVeryLongCompanyName.MyVeryLongProductName.SomeNamespace1.SomeType.MyActualNestedType
with a single symbol. When Ceras needs to write the type name your binder would make it so only ~1.SomeType.MyActualNestedType gets written. And at deserialization time your TypeBinder knows that types that begin with ~1. are just a shorthand for a longer type name and reverses the change again.
Just implement ITypeBinder and set it in the SerializerConfig
(todo: write a tutorial step for this)
Report it as an issue. If it's a common type I'll most likely add a dedicated built-in formatter for it.