I noticed while working with Odata and Mongo that some queries were very inefficient.
I believe I have identified the root cause of the problem which is described here: AspNetCoreOData/Issues/1490/Useless Expression.Condition when parsing IsOf
Although the bug needs to be fixed on the OData side, I believe the Mongo driver could do better and should have simplified the expression. The case presented is simple, but it's likely that many optimizations could result from such a change.
At a minimum, the driver should have simplified the expression:
Unable to find source-code formatter for language: csharp. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml
o => o.SomeProperty.Any(o2 => o2 is SomeType ? true : false)
Mongo query:
{ "$expr" : { "$anyElementTrue" : { "$map" : { "input" : "$SomeProperty", "as" : "se", "in" : { "$cond" : { "if" : { "$eq" : ["$$se._t", "SomeType"] }, "then" : true, "else" : false } } } } } }
To:
Unable to find source-code formatter for language: csharp. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml
o => o.SomeProperty.Any(o2 => o2 is SomeType)
Mongo query:
{ "SomeProperty" : { "$elemMatch" : { "_t" : "SomeType" } } }
But I imagine the biggest gains would be to do it recursively. And include Expression.Not unary expression.