-
Notifications
You must be signed in to change notification settings - Fork 21.9k
Add dirty methods for store accessors #19333
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
Conversation
29d7752
to
942fe13
Compare
@rafaelfranca @sgrif Any feedback on that? |
I think that this falls into the bucket of "we should just promote store accessors to proper attributes". |
@sgrif Interesting. Is anyone struggling with that? |
Just found myself struggling with the absence of accessors dirty methods. Maybe, we should revamp this PR? It's pretty simple but useful change, IMO. |
Years have passed. I'm still missing this 😢 Maybe, Rails 6 is a good place for this feature? @kaspth WDYT? |
define_method("#{key}_changed?") do | ||
return false unless attribute_changed?(store_attribute) | ||
prev_store, new_store = changes[store_attribute] | ||
prev_store.try(:[], key) != new_store.try(:[], key) |
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.
Let's go with &.dig(key)
instead of the try.
# u.color_changed? # => true | ||
# u.color_was # => 'black' | ||
# u.color_change # => ['black', 'red'] | ||
# | ||
# # Add additional accessors to an existing store through store_accessor | ||
# class SuperUser < User | ||
# store_accessor :settings, :privileges, :servants |
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.
These'll also get change tracking too, right?
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.
Could you please explain, what did you mean here?
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.
It's basically what you demonstrate in your PR description. I'm just asking if store_accessor :color
also adds color_changed?
etc. or if we missed it and only store :settings, accessors: %i( color )
would get it.
65698c8
to
619c038
Compare
@kaspth Hey! Thanks for the feedback! I've addressed all the comments and actualized the PR by adding saved changes helpers as well. |
This feature proves you should never ever give up! 👍 |
What's the easiest way to backport this to Rails 4.2? |
@wbcasey You can patch ActiveSupport.on_load(:active_record) do
ActiveRecord::Store::ClassMethods.prepend(Module.new do
def store_accessor(store_name, *keys)
super
keys = keys.flatten
_store_accessors_module.module_eval do
keys.each do |key|
define_method("#{key}_changed?") do
return false unless attribute_changed?(store_name)
prev_store, new_store = changes[store_name]
prev_store&.dig(key) != new_store&.dig(key)
end
end
# ...
end
end
end)
end |
@wbcasey defining those methods there? |
@LucasArruda basically back-porting the "dirty" functionality. I tried just bringing it in, but some of the API surface has changed between 4.2 and 6.x |
Example:
Also, force
Model.stored_attributes[:store]
array to contain string keys.