New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CSHARP-1356: Fix Any workflow with Contains method. #13
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See prelimary comment about what (not how) we are translating some of these LINQ expressions to.
tests/MongoDB.Driver.Tests/Linq/Translators/PredicateTranslatorTests.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused about the syntax for {$elemMatch: {$in: {}}. It obviously works, but why do we need $elemMatch in there at all?
@@ -163,8 +161,10 @@ private FilterDefinition<BsonDocument> TranslateAnd(BinaryExpression node) | |||
return null; | |||
} | |||
|
|||
private bool CanAnyBeRenderedWithoutElemMatch(Expression node) | |||
private bool CanAnyBeRenderedWithoutElemMatch(Expression node, out bool doNotUseExpressionParamInQueryGeneration) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
having booleans that are negated is always difficult to think about. I believe it would be better for this to be useExpressionParamInQueryGeneration
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I will rename this param
tests/MongoDB.Driver.Tests/Linq/Translators/PredicateTranslatorTests.cs
Outdated
Show resolved
Hide resolved
I amend my previous statement about the DocumentToFieldConverter... It is necessary and looks fine as it is. |
See proposed changes (with comments) here: |
3b1611f
to
b86f222
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM pending one comment where I asked @craiggwilson to LGTM the removal of the VisitPipeline method in the DocumentToFieldConverter class.
protected internal override Expression VisitPipeline(PipelineExpression node) | ||
{ | ||
return node; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@craiggwilson I would like you to LGTM that it is OK to remove this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, let's assume that I put it here for some reason (whatever that is). Is there any overriding reason to actually remove this other than "we don't know why it's here". If it's not causing issues, I don't see a reason to remove it just 'cause.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't remove it Dmitry's changes don't work.
So we should remove it, unless you can remember why you were suppressing visiting a PipelineExpression.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, if we have to remove it for things to work, then let's remove it.
8899da8
to
d242d05
Compare
No description provided.