-
Notifications
You must be signed in to change notification settings - Fork 357
Fix cast in expand #2300
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
Merged
Merged
Fix cast in expand #2300
Changes from all commits
Commits
Show all changes
15 commits
Select commit
Hold shift + click to select a range
bed3398
Fix cast in expand
KenitoInc 5fba1dd
Fix select expand issue
KenitoInc 390b5eb
Fix expand bug and add tests
KenitoInc 4dc02f2
Fix BindCompute and BindApply
KenitoInc e078e9c
Add test
KenitoInc baf500a
Add apply tests
KenitoInc 3bb2a12
Handle types of TypeSegment better
KenitoInc b4cb609
Add tests for Select structured type
KenitoInc 6aeaa3c
code refactoring
KenitoInc ff060a1
Fix build failure
KenitoInc b685d36
update how we handle collection types
KenitoInc 8d62b20
Code optimizations
KenitoInc 2228ef2
Fix targetType for TypeSegment
KenitoInc 7f4ff99
Revert unnecessary change
KenitoInc 6a4c552
Revert unnecessary change
KenitoInc File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
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.
Out of curiosity, why does the
elementTypeReferencedefault to null when there's no derived type segment as opposed to defaulting to the type of the property being expanded? #ResolvedThere 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.
It's null since we can get it from the expanded property in these lines
odata.net/src/Microsoft.OData.Core/UriParser/Binders/SelectExpandBinder.cs
Lines 924 to 929 in 1452522
Uh oh!
There was an error while loading. Please reload this page.
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 see that we are getting the type in SelectExpandBinder, but what is the contract with BindFilter, BindOrderby, etc? These private functions take an elementType which gets passed eventually to CreateBindingState where the logic is to fall back to the navigationSource, if it's not otherwise specified. But it's not clear in the various private methods that the elementType is nullable, and future code could make invalid assumptions about whether it may be null. If that private CreateBindingState method is only reached through these methods, would it be cleaner to compute the elementType from the targetNavigationSource here so it is never null in subsequent methods? Alternatively, maybe at least clarify in the description of the elementType parameter to the various methods (i.e., line 529) "The target element type if different from the type of the target navigation source." Logic is sound, I just want us to consider what is the cleaner/more intuitive contract for maintainability.
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.
@mikepizzo I have updated the description.