[Feature] IN operator #1165
[Feature] IN operator #1165
Conversation
…e to support feature. Adding corresponding tests.
… have IList of ConstantNode instead of generic object.
| @@ -285,7 +285,7 @@ public virtual bool Read() | |||
| } | |||
|
|
|||
| // We might see end of array here | |||
| if (this.characterBuffer[this.tokenStartIndex] == ']') | |||
| if (this.characterBuffer[this.tokenStartIndex] == ']' || this.characterBuffer[this.tokenStartIndex] == ')') | |||
| { | |||
There was a problem hiding this comment.
Will this also allow me to terminate a JSON array with a closing parens? i.e., does "names": ["bob","sue") now parse as valid? #Closed
There was a problem hiding this comment.
Great question. The answer is no and I don't have an existing test case for this but I've tested it. I have a test case for the vice-versa scenario (since we currently don't allow bracketed collections in IN expression):
public void FilterWithInOperationWithMismatchedClosureCollection()
{
Action parse = () => ParseFilter("ID in (1,2,3]", HardCodedTestModel.TestModel, HardCodedTestModel.GetPersonType());
parse.ShouldThrow<ODataException>().WithMessage(ODataErrorStrings.ExpressionLexer_UnbalancedBracketExpression);
}I added the test case that you described with the closing parens and will update the PR after we discuss the other items that you have. No product code changes needed as the parser already takes care of this case. #Closed
Let's talk through how/where JsonReader gets called for this case; it would be nice not to have to add parens parsing to the JSON reader, as it is not a JSON concept. Refers to: src/Microsoft.OData.Core/Json/JsonReader.cs:220 in becc74f. [](commit_id = becc74f, deletion_comment = False) |
| this.left = left; | ||
| this.right = right; | ||
|
|
||
| if (this.left.GetEdmTypeReference().Definition != this.right.ItemType.Definition) |
There was a problem hiding this comment.
this.left.GetEdmTypeReference().Definition != this.right.ItemType.Definition [](start = 16, length = 76)
We should support the type of the right node collection being comparable to the type of the left node (including being derived from the type of the left node). See EdmLibraryExtensions.IsAssignableFrom. #Closed
There was a problem hiding this comment.
Thanks for the catch, I think I had forgotten to jot down the point regarding derived types during code review. Regarding supporting comparable types, is there a function or API that you're specifically referring to or is what I currently have in the code of comparing the definitions sufficient? #Closed
… logic and instead, passing in a bracket-based collection and keeping the parens-based collection as the literal text
* Implementing IN operator. Define new InNode and CollectionConstantNode to support feature. Adding corresponding tests. * The ABNF indicates that brackets are supported for enclosing the lists; however, this particular feature is currently excluded from implementation due to some breaking changes in code. For now, lists are supported only with parentheses.
* Implementing IN operator. Define new InNode and CollectionConstantNode to support feature. Adding corresponding tests. * The ABNF indicates that brackets are supported for enclosing the lists; however, this particular feature is currently excluded from implementation due to some breaking changes in code. For now, lists are supported only with parentheses.
Issues
#1147
Description
Implementation of the IN operator as part of the OData 4.01 spec (see ABNF).
This PR includes the IN operator feature, which includes a new class InNode, modifications to the expression lexer to recognize the "in" keyword, and unit and functional test cases.
Exclusions of implementation:
Checklist (Uncheck if it is not completed)