In CSHARP-5375 we removed the KnownSerializerFinder thinking that it was no longer needed.
We have since discovered a few scenarios that actually can only be solved with something similar to the KnownSerializerFinder that we removed.
We had good reasons to remove the KnownSerializerFinder, so I don't think we should simply bring it back as it was.
What would probably work well is a new approach similar to the KnownSerializerFinder that actually deduces which serializer to use at various nodes in the expression tree starting from nodes for which the serializer is known. This is different from the original KnownSerializerFinder which just relied on which serializers it had "seen", but didn't apply any rules as to where that serializer might then be appropriately used. Another difference is that information about serializers needs to move in two directions, from higher to lower nodes as well as from lower to higher nodes (the KnownSerializerFinder only propagated information upwards).
- is depended on by
-
CSHARP-5435 NotSupportedException when using Set with sub-documents in an Update with Aggregation Pipeline
-
- Blocked
-
-
CSHARP-5519 In a filter Any with array constant and predicate comparing item to field should translate to $in
-
- Blocked
-
-
CSHARP-4820 Configured serializer is not called in some cases, resulting in incorrect serialization
-
- Blocked
-
-
CSHARP-5532 BSON Representations not respected in nested objects in LINQ3
-
- In Progress
-
-
CSHARP-4819 ReplaceWith not respecting custom element name configured by the serializer
-
- In Progress
-
-
CSHARP-5461 Add targetSerializer parameter to Translate methods
-
- Closed
-
- related to
-
CSHARP-5375 Remove KnownSerializerRegistry
-
- Closed
-