Allow reload to be default_scoped
#40805
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
`reload` is not `default_scoped` by default because you could be creating a record that does not match your default scope and therefore `reload` wouldn't find the record. However, in the case of sharding an application you may want `reload` to support `default_scope` because you'll always have the correct scope set. To accomplish this I added a new method that checks if there are any default scopes defined that are set to run for `all_queries`. If there are then don't `unscope` the find methods. If there is a case where you do want the default scope to apply to all queries but be able to turn that off, I've added a `unscoped` option to `reload`. This would use the original behavior regardless of whether the `default_scope` was used for all queries. Additionally, this exposes a new public method `default_scopes?` that returns true if there are default scopes. If `all_queries` is passed to `default_scopes?` the method will only return true if there is a default scope for the model that has `all_queries` set to true. If there are no default scopes with `all_queries` then it will return false.
eileencodes
force-pushed
the
default-scope-on-reload
branch
from
c4f581c
to
a3343d2
Compare
|
|
eileencodes
added a commit
to eileencodes/rails
that referenced
this pull request
Feb 11, 2021
Similar to rails#40720 and rails#40805 this change allows for the `scoping` method to apply to all queries in the block. Previously this would only apply to queries on the class and not the instance. Ie `Post.create`, Post.all`, but not `post.update`, or `post.delete`. The change here will create a global scope that is applied to all queries for a relation for the duration of the block. Benefits: This change allows applications to add a scope to any query for the duration of a block. This is useful for applications using sharding to be able to control the query without requiring a `default_scope`. This is useful if you want to have more control over when a `scoping` is used on a relation. This also brings `scoping` in parity with the behavior of `default_scope` so there are less surprises between the behavior of these two methods. There are a caveats to this behavior: 1) The `scoping` only applies to objects of the same type. IE you cannot scope `Post.where(blog_id: 1).scoping` and then expect `post.comments` will apply `blog_id = 1` to the `Comment` query. This is not possible because the scope is `posts.blog_id = 1` and we can't apply the `posts` scope to a `comments` query. To solve this, scopes must be nested. 2) If a block is scoped to `all_queries` it cannot be unscoped without exiting the block. I couldn't find a way around this but ActiveRecord scoping is a bit complex and turning off `all_queries` when it's already on in nested scoping blocks had interesting behavior that I decided was best left out.
4 tasks
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.
reloadis notdefault_scopedby default because you could becreating a record that does not match your default scope and therefore
reloadwouldn't find the record.However, in the case of sharding an application you may want
reloadtosupport
default_scopebecause you'll always have the correct scopeset. To accomplish this I added a new method that checks if there are
any default scopes defined that are set to run for
all_queries. Ifthere are then don't
unscopethe find methods.If there is a case where you do want the default scope to apply to all
queries but be able to turn that off, I've added a
unscopedoption toreload. This would use the original behavior regardless of whether thedefault_scopewas used for all queries.Additionally, this exposes a new public method
default_scopes?thatreturns true if there are default scopes. If
all_queriesis passed todefault_scopes?the method will only return true if there is a defaultscope for the model that has
all_queriesset to true. If there are nodefault scopes with
all_queriesthen it will return false.