-
Notifications
You must be signed in to change notification settings - Fork 174
Serialization attributes
You can use custom attributes to control member serialization.
You have three options to specify a type is serializable with MessagePack serializers. The runtime trying followling order.
- If the target type has any members which are marked with
MessagePackMemberAttribute
, then only those members will be serialized in opt-in manner. - If the target type is marked with
DataContractAttribute
, then members withDataMemberAttribute
will only be serialized in opt-in manner. - Else, members which are NOT marked with
NonSerializedAttribute
will be serialized in opt-out manner.
Note that using MessagePackMemberAttribute
is prefered. Remainings exist just for interoperability for existent frameworks.
This attribute specifies following MessagePack dedicated metadata.
Specifies numeric identifier of the member. IDs should be continuous and shall be started with 0. Missing IDs are considered that those members are omitted in the runtime (CTS type) representation. That is, the nil will be emittes in serialization, the values at those IDs will be skipped in deserialization.
There are three options for what the nil implies.
-
MemberDefault
means that the nil will be interpreted as the member is omitted, so unpacker does not ANY action for corresponds member. This option will not affect serialization. This value corresponds tooptional
in the IDL. -
Null
means that the nil will be interpreted asnull
. As you see, the type must be reference type orNullable<T>
value type. This value corresponds tonullable required
in the IDL. -
Prohibit
means that serialized value must not be nil even if the member type is reference type. This value corresponds torequired
in the IDL. This option will affect both of serialization and deserialization process. By the way, when the nil is emitting or deserializing,SerializationException
will be thrown.
Note: Respecting to the IDL design, members are required by default.
As mentioned above, you can use DataContractAttribute
to specify MessagePack serialization. It may be useful when you expose entities as Web Services on the same time, for example.
If any members of the type are not marked with MessagePackMemberAttribute
and the type itself is not qualifed with DataContractAttribute
, all read/write PUBLIC members (that is, fields which are not readonly and properties which have both of getter and setter) are serialized. This is useful for casual cases, but you should explicitly annotate members for many production scenarios.
You can exclude members from serialization via NonSerializedAttribute
.
For [MessagePackKnownType]
, [MessagePackKnownCollectionItemType]
, [MessagePackKnownDictionaryKeyType]
, [MessagePackKnownTupleItemType]
, [MessagePackRuntimeType]
, [MessagePackRuntimeCollectionItemType]
, [MessagePackRuntimeDictionaryKeyType]
, and [MessagePackRuntimeTupleItemType]
see [Polymorphism].