-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Affects Version/s: None
-
Component/s: LINQ
-
None
-
None
-
Dotnet Drivers
-
None
-
None
-
None
-
None
-
None
-
None
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 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 version of the KnownSerializerFinder that actually infers 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.
- 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-5532 BSON Representations not respected in nested objects in LINQ3
-
- Blocked
-
-
CSHARP-4819 ReplaceWith not respecting custom element name configured by the serializer
-
- Blocked
-
-
CSHARP-5461 Add targetSerializer parameter to Translate methods
-
- Blocked
-