Support sproc input/output parameters on non-concurrency-token properties #28908
Conversation
This file contains 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
|
Ok, how about this: We change the Metadata API to use a different enum for |
|
@AndriySvyryd did the changes as we discussed, take a look. (Note that this doesn't include creating our own ParameterDirection, I'll do that in a separate PR) |
AndriySvyryd
reviewed
Sep 9, 2022
src/EFCore.Relational/Infrastructure/RelationalModelValidator.cs
Outdated
Show resolved
Hide resolved
AndriySvyryd
approved these changes
Sep 9, 2022
roji
force-pushed
the
InputOutput
branch
2 times, most recently
from
a63bde5
to
deebb2d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
@AndriySvyryd @ajcvickers one last design thought on this... This PR makes in/out parameters means "always both send and receive", as discussed. If, in the future, we implement optional sproc parameters with sentinel values, it would be a breaking change to change the meaning of in/out to "write only if the user set the property, read only if they didn't" (which is our regular SQL behavior). In other words, in order to allow the user to sometimes provide a value and sometimes not (in different commands) - today, without optional params/sentinels - we're making it so that their value is always sent and read back (in the same command).
I'm a bit concerned that we're painting ourselves into a corner; ideally, the write-and-read within the same command would be triggered by a separate opt-in, since it's probably really rare. Not merging this PR would mean users currently must choose either input or output, but not both, which doesn't seem too bad. If/when we have optional/sentinel parameters, they'd be able to do input/output without reading back values when they provide them.
But we've already discussed this too much... If you're guys this we should do this, I'm OK with it.
Closes #28704