add DB level propagation for the Unscoped flag #7007
Merged
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
jinzhu
reviewed
Jun 12, 2024
tests/hooks_test.go
Outdated
| } | ||
| DB.Model(&Product6{}).Create(&p) | ||
|
|
||
| DB.PropagateUnscoped = true |
There was a problem hiding this comment.
indeed. pushed a fix and updated the test
|
Can you add some doc to gorm.io, thank you |
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.
What did this pull request do?
This PR adds
PropagateUnscopedtoDB'sConfig. Its purpose is to allow propagation of the parentStatement'sUnscopedflag to nested statements.Should this become the default behavior?
Is there any scenario where
getInstance()where we don't want this flag to propagate? For the record, all tests pass if we just persist theUnscopedstate whenclone == 1.I just didn't want to introduce what may be a breaking change in more complex production environments for which gorm's tests don't offer coverage therefore this is a disabled by default flag.
Regardless, this kind of change should not be introduced without a flag to panic control it.
User Case Description
When one wants to create advanced hooks which leverage not just the usual Before/After but also
StatementModifierhooks while reusing theUnscopedstate of the parent statement, it can be expected that the flag propagates to all child hooks.One can, and that's what we find ourselves doing more often than not, is to store the original tx/stmt's
Unscopedstate and adding repeated extra lines of code where one wants to keep the state after a nestedDeleteorModelcalls done inside hooks - arguably, in every possibly nested hook.Since for some, or even all, use cases, one just wants to have
Unscopedpropagated to all nested statements, this is a way cleaner and non intrusive solution to address such challenge.