-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Added metadata for complextypes for AddViews / TVF in RelationalModel #36894
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
Open
kirolous-nashaat
wants to merge
2
commits into
dotnet:main
Choose a base branch
from
kirolous-nashaat:main
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
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
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
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
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
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.
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.
@roji What do you think about this?
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.
Thanks for the ping.
Yeah, I don't we should be doing this - not in this PR, in any case. We don't currently flow "for query" vs "for update" into the query pipeline for any other case; our current approach to this is instead to rewrite the main target table from the view to the table, specifically when translating ExecuteUpdate (see code). The advantage of that approach is keeping the view vs. table concern out of the query pipeline, and dealing with it only where it's relevant.
So the existing code (linked to above) should take care of everything (including for complex properties) - in fact I'm surprised it does not do so already. What exactly prompted you to introduce this change?
I'm also noting that we should only be referencing the table for the mutation; any property accesses elsewhere (e.g. in the WHERE clause) should reference the view.
If we do want to change the way we're dealing with this and filter the information into the query pipeline, we should probably do this more generally in a separate PR, and remove the current code switching from the view to the table which I linked to above.
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.
please check this comment for initial thoughts about the issue
#34627 (comment)
before the change, we didnt have view metadata for complex types
the test mentioned above broke cuz of this change
it was relying on complex props not having mapping in the view ( container expression ) , it throws key not found , as expected in the test
after the change
now we have metadata for complex types, execute update find a mapping in the view
try to execute something like this
update viewx set column = ..
which throws exception cuz viewx isnot a table and can't be updated
so to keep the old test behavior and not break it, i had to know if i need table mappings only or viewortablemappings
select expression mapping of complex property does use getviewortablemapping
which return = view ?? table
so you need to distinguish if you need select expression for update / read statements accordingly
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.
not sure about this part.
for example i want to update table where a column is x
there is a where condition but because we are in an update statement we cant use the view at all
so mutation uses table regardless of where/set
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 as I wrote above, we already have code in the ExecuteUpdate translation which is supposed to take care of this - I'm wondering what it doesn't work.
Note that I'm not necessarily opposed to the approach here: flowing forUpdate in like this PR proposes is in some ways probably better than the current approach of doing a translation, and then rewriting that translation to transform the view to the table (always better do just do the right thing immediately rather than do one thing and rewrite later, and this would certainly simplify the ExecuteUpdate logic by removing the transformation...).
But if we do go in this direction, we should switch to it fully, rather than doing one thing for complex properties and another for regular entities.
@AndriySvyryd any thoughts?
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.
so @roji , you mean i should try to make the execute update work or do we still need it to fail in case of complex types + view + table ?
by figuring out why the snippet you sent didn't work as expected
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.
ExecuteUpdate definitely shouldn't fail for complex types, though we can also decide to handle that separately if we want - it's OK for this PR to just handle the metadata side, and then a separate issue/PR for making sure everything works in the query pipeline.
But in general, yes, we should figure out why the existing code (which I sent) doesn't take care of things. As an alternative, we could decide that your way (flowing
forUpdateinto the query pipeline) is better, but then we need everything to work that way - include non-complex (entity) types. Your PR, as is, would mean that there are two different approaches to the same problem: for regular entity types, the code snippet I sent handles this in ExecuteUpdate (by rewriting the view to a table), whereas for complex types, we flowforUpdatein. We shouldn't have two ways of doing this.Am mainly wanting to hear @AndriySvyryd's opinion on this.