Support user defined type serializers

[jorgebay]

Sample usage, using a custom BigDecimalinstead of C# decimal:

var cluster = Cluster.Builder()
    .AddContactPoint(TestCluster.InitialContactPoint)
    .WithTypeSerializers(new TypeSerializerDefinitions()
        .Define(new BigDecimalSerializer()))
    .Build();
var session = cluster.Connect();
var row = session.Execute(statement).First();
BigDecimal value = row.GetValue<BigDecimal>("value");

[jorgebay]

Should allow multiple custom serializers

[collinsauve]

Via code review (rather than empirically), it looks like the issue in I brought up CSHARP-420 is fixed with the new serialization.

[collinsauve]

P.S. might also need to deal with open-vs-closed generic type serializers. ie can I have a serializer that is for IEnumerable<> + one that is for IEnumerable<string>? It should obvious find the most-specific one. This becomes even more complex if you have IEnumerable<IMyInterface<>>, etc! (ugh!)

[jorgebay]

Thanks for taking the time to review it @collinsauve !

User-defined serializers for map/list/set are not supported, list and set can be represented in multiple types in the C# driver: are originally deserialized as arrays and are then yielded as List, SortedSet, HashSet, ..., or as an Array depending on the type provided by the user when using Row.GetValue(string) this is mainly to support the previous behaviour and avoid introducing breaking changes.
If the user provides a serializer for given type (ie: atype), the Serializer which work for list<atype>, set<atype>, in the same way as the rest of types.

We could allow user-defined serializers for tuples but it will require changing how the checks are made (there is no public base class for Tuple<T1>, Tuple<T1, T2>, Tuple<T1, T2, T3> (thanks .NET!) and I personally don't see the point of mapping tuples to a different class/struct.

Serialization and deserialization performance should not be penalized when adding extra TypeSerializers, that is why we need to use a structure for which the lookup is independent to the amount of items (in this case Dictionary<, >), using the Type hash. Also note that ITypeSerializer is an internal interface.

[collinsauve]

Sorry @jorgebay my P.S. was regarding another, longer comment I thought I had made directly on a diff on Friday. Now I can't seem to find my comment.

I was actually trying to point out that if I have a type A, with a serializer for it, and then a class B that inherits from A, the current implementation will not be able to locate the serializer. This does not seem to be constrained to collection types.

[collinsauve]

Here's my original comment, I am copying it below:

Not sure how severe the following problem is, but I thought I'd bring it up:

If using a custom ITypeSerializer the runtime type of the object being serialized has to exactly match the ITypeSerializer.Type. For example, if I have class B inherits from A, a serializer for A, and then attempt to serialize an instance of B, it appears as though it will not find the A serializer.

Ideally the serializer would locate the ITypeSerializer whose type IsAssignableFrom the runtime type being serialized, but has the highest specificity. Obviously this would be slower than the current dictionary lookup, so would probably want to cache the resulting runtime-type->ITypeSerializer mapping.

Here's a very quick example of how you might find the serializer with the highest-specificity: https://dotnetfiddle.net/n3G7zI

For the following types:

public class A { }
public class B : A { }
public interface IInterface { }
public class C : IInterface { }
public class D : B, IInterface { }

With serializers for A, B, and IInterface, it should find these runtime-type => serializer mappings:

A => TypeSerializer for A
B => TypeSerializer for B
C => TypeSerializer for IInterface
D => TypeSerializer for B

[jorgebay]

Github removes it from the pull request thread when the comment is on the commit instead of the files tab, but I was able to see it the first time, thanks anyway.

Type serializers work on the assumption that for 1 CQL type there is one CLR type (1 to 1), regardless the inheritance.
By hashing it by type, we ensure that the lookup is O(1) operation, instead of Linq where that is a O(n) operation.

I was actually trying to point out that if I have a type A, with a serializer for it, and then a class B that inherits from A, the current implementation will not be able to locate the serializer.

Type B and type A have different hash codes, so they will use different serializers, regardless if B inherits from A.

[collinsauve]

Okay, as long as this is expected :)

[landim]

lgtm 👍

[jorgebay]

Merged.
Thanks @collinsauve and @landim for your input.