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
Revert #22610 by default and make it opt-in #41412
base: main
Are you sure you want to change the base?
Revert #22610 by default and make it opt-in #41412
Conversation
511333d
to
3aacc11
Compare
activemodel/test/cases/validations/inclusion_validation_test.rb
Outdated
Show resolved
Hide resolved
4889b5a
to
37b34fe
Compare
@@ -24,7 +26,7 @@ def include?(record, value) | |||
delimiter | |||
end | |||
|
|||
if value.is_a?(Array) | |||
if value.is_a?(Array) && options[:all] == true |
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.
The idea behind the all
name is that we can introduce also an any
option (use .any?
instead of .all?
) which makes sense for the exclusion
validation, check cases such as: #22610 (comment)
4c108a6
to
e2c2e20
Compare
@@ -33,6 +34,8 @@ module HelperMethods | |||
# with <tt>Range#cover?</tt>, otherwise with <tt>include?</tt>. When using | |||
# a proc or lambda the instance under validation is passed as an argument. | |||
# * <tt>:within</tt> - A synonym(or alias) for <tt>:in</tt> | |||
# * <tt>:all</tt> - If attribute is an <tt>Array</tt> validates the inclusion of |
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 didn't document this option for validates_exclusion_of
(even if is available in the code path) because I couldn't find a valid use case.
@rafaelfranca could you take a peek 🙏 ? |
Sorry for being out of the loop on this one. I think this looks good. 👍 My initial implementation was actually based around an option (see the pull request description), |
Any chance someone from the core team could take a look at this? 🙇 |
2cbb005
to
fb0b09b
Compare
bump 🏓 |
fb0b09b
to
e270d5a
Compare
e270d5a
to
56a87db
Compare
@zzak sorry to tag you but you're super active, maybe you can take a look a this PR too? It's been there for a while 😄 |
def test_validates_inclusion_of_with_array_value | ||
Person.validates_inclusion_of :karma, in: %w( abe monkey ) | ||
def test_validates_inclusion_of_with_array_value_and_all_option_is_true | ||
Person.validates_inclusion_of :karma, in: %w( abe monkey ), all: true |
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.
Is all
required for this test to pass? Or were you modifying an existing test on purpose 🤔
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.
Yes all: true
is required, this is basically the purpose of this PR: reverting the default and making this behaviour opt-in
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.
@intrip What happens if we remove all: true
?
I'm hesitant to revert the old behavior as this likely already cost some upgrade cycles for folks, to revert that behavior may be confusing. If we kept the current behavior, is there still a way to opt-out?
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.
@zzak
I understand your point, honestly I've just followed #41051 (comment) suggestion.
Changing this to opt-out is dead simple in any case and I don't mind following a more conservative approach.
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 will trust @rafaelfranca here, since his original suggestion was to revert to the old behavior and opt-in. 🙏
Just making sure we didn't at least consider the conservative approach first.
@intrip I took a quick look, this one tab was open all day.. The approach seems good to me? But I think it's better to wait for someone like @rafaelfranca who has more context here. 🙏 |
56a87db
to
afa899a
Compare
afa899a
to
650623f
Compare
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
still relevant |
650623f
to
18fe512
Compare
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
ping |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
pong |
Change rails#22610 in order to revert the behaviour by default. If the option `all: true` is given applies the new behaviour.
18fe512
to
e481fc8
Compare
Is there another way to concisely express a validation that functions the way |
@elliottmason Are you able to try this PR in your app? It would be good to know if there are any regressions before this is merged. |
Thanks for the suggestion @zzak I will do that and report my findings. |
@zzak @rafaelfranca this fix has been around for awhile - any chance we could get this merged? |
@elliottmason Did you have any luck with this PR? |
We're reaching 6.1 now, and this came up. Are there plans to merge this? |
My current solution to this is: - exclusion: { in: [nil] }
+ length: { minimum: 0, allow_nil: false, message: "can't be nil" } |
Summary
Change #22610 in order to revert the behaviour by default.
If the option
all: true
is given applies the new behaviour.Fixes #41051