You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After the deep merge, the id of the ActiveRecord instance is nil. Any clues? I haven't looked into the source, yet, but remember hashie was doing some automatic subclassing somewhere when cloning.
The text was updated successfully, but these errors were encountered:
Hey Nick! #deep_merge performs a #deep_dup on non-Hashes. I believe ActiveRecord models are #duplicable? which means they have #dup called on them. That exhibits the behavior that you're seeing.
Hashie doesn't support rich objects well and never has. It's more of a data munging library that concerns itself with primitives.
Introducing a workaround for ActiveRecord is tricky because we can't depend on Rails constants in the library, but I would be open to a patch that doesn't break backwards compatibility.
Hey Michael! Thanks for responding so quickly! 💚 My first question here would be (regarding hashie as a beautiful munger for primitive datatypes!!!), why are you calling dup on a "flat" object in the first place?
Hey folks,
I might be insane, but I'm experiencing something weird when using
#deep_merge
. In a tiny Rails 7 app, I have aDiagram
ActiveRecord model.After the deep merge, the
id
of theActiveRecord
instance is nil. Any clues? I haven't looked into the source, yet, but remember hashie was doing some automatic subclassing somewhere when cloning.The text was updated successfully, but these errors were encountered: