-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Unknown
-
Affects Version/s: None
-
Component/s: None
-
None
-
Dotnet Drivers
This ticket applies to the code that has been (or will be) added as part of CSHARP-1585.
`FilterDefinitionBuilder` contains the following `ElemMatch` overloads:
public FilterDefinition<TDocument> ElemMatch<TItem>(FilterDefinition<TItem> impliedElementFilter) // where TDocument : IEnumerable<TItem> (can only be checked at runtime) public FilterDefinition<TDocument> ElemMatch<TItem>(FieldDefinition<TDocument> field, FilterDefinition<TItem> filter) // where TField : IEnumerable<TItem> (can only be checked at runtime)
(ignoring a few other overloads that call the main ones)
The type constraints in the comments cannot be checked at compile time due to limitations in how the `field` parameter is defined.
We are postponing enforcing these constraints at runtime due to concerns about possible backward breaking changes when using `ElemMatch` with untyped queries using the `BsonDocument` object model.
If the user writes an invalid query that violates these type constraints the result will be that an invalid query is sent to the server. The server does not return an error in this case, it simply returns no matching documents.
Eventually it would be better to catch such an error client side, so the user knows that the query they wrote has something wrong with it.
- is related to
-
CSHARP-1585 Support for $elemMatch filters directly against the elements with no field name
-
- Closed
-