Make cache types serialization friendly

[maca88]

Here is an attempt to make the serialization of cache types easier in order to support other serializers like XmlSerializer, DataContractSerializer and others. I've added WIP in the title as the current tests are failing because of types that don't have a proper cacheable representation, which is covered by #1765. There is a limitation when a XmlSerializer is used as it does not support DateTimeOffset and TimeSpan types, which I wouldn't worry too much as DataContractSerializer should be the preferred serializer for xml as it is faster.

[hazzik]

XmlSerializer ... does not support DateTimeOffset and TimeSpan types

Implement IXmlSerializable?

[fredericDelaporte]

Should we bother supporting xml serialization at all? XML adds a big overhead to the data size, it is an ill suited format for caching in my opinion.

[maca88]

Implement IXmlSerializable?

That is not possible, if you try that you will get an exception: 'NHibernate.Cache.Entry.CacheEntry' cannot be IXmlSerializable and have DataContractAttribute attribute. DataContract and DataMember attributes were added because Json.net also supports them so that only the members that have a DataMember attribute will be serialized, otherwise also properites with just a public getter will be serialized (e.g. CacheLock.IsLock). In order to avoid having something partially supported we could remove the added XmlInclude attributes. About the KnownType attributes, they can be also removed as they can be provided as the second argument of the DataContractSerializer constructor. So we have to following options:

• Leave as it is
• Remove the XmlInclude attributes
• Remove the XmlInclude and KnownType attributes
• Remove all added attributes
• Remove KnownType, DataContract and DataMember attributes and implement IXmlSerializable

For me the first three are all fine, keeping the DataContract and DataMember attributes in order to control the serialization.

Should we bother supporting xml serialization at all?

Not really, I've added the XmlInclude and KnownType attributes by the way and I wouldn't mind if we remove them.

[hazzik]

Number 3 please

[fredericDelaporte]

2 or 3. Keeping the KnowType reduces the knowledge required to serialize things. Removing them avoids to have to maintain them. I am more in favor of 2 than 3, but I am ok with 3 too.

[maca88]

Then 3 it is.

[hazzik]

Stupid "GitHub-flavored markdown", I did not mean to write in bold my previous comment. What I meant is "Number 3 please". But, because because hash followed by a number would be interpreted as a issue/pr number. And because hash was the first character of the line it has been interpreted as a header.

[fredericDelaporte]

So, the //TODO: assumes all collections disassemble to an array! has moved here indeed.

[fredericDelaporte]

So, the //TODO: assumes all collections disassemble to an array! has moved here indeed.

And here too. Then why not keeping it in the CollectionCacheEntry class?

[maca88]

You are right, I got confused as IPersistentCollection.InitializeFromCache and IPersistentCollection.Disassemble are using object which I think it should be changed to object[] in the future as all implementations are casting/returning it.