MONGOID-5825 Do not update timestamp on destroyed

[comandeo-mongo]

No description provided.

[johnnyshields]

This is likely going to break apps which use Mongoid::Paranoia (which my app does heavily). I think it makes sense to consider destroying a form of update; many times you want to use the updated_at value to check if there has been any form of update on an object, including destroying it.

It's also worth considering this behavior has existed this way for 10+ years...

Looking at MONGOID-5825, are there other possible solutions to avoid the frozen error?

[jamis]

@johnnyshields, can you clarify how this will affect Mongoid::Paranoia? All this PR does is prevent the timestamps from being applied to a frozen object. Is there a valid situation where timestamping a frozen object is an acceptable action?

[comandeo-mongo]

@johnnyshields do you use this one - https://github.com/simi/mongoid_paranoia ?

[johnnyshields]

Yep, I use that one. Come to think of it, I just remembered I monkey patched my app to set updated_at when things are deleted, so maybe this wont break anything after all…

Still, I wonder if there are other possible solutions to the original ticket? i.e. does it make sense to “freeze” objects in ruby when they are destroyed? Couldn’t similar errors happen elsewhere?

[comandeo-mongo]

I ran mongoid_paranoia tests agains this branch, and they all pass. I understand that this is not a 100% guarantee, but still a good sign.

As to the change itself - I agree with @jamis , I do not see why it can be destructive. Without this PR an attempt to set timestamps raises can't modify frozen Hash error. With this PR there is no attempt to set timestamps. So, created_at and updated_at are not set in both cases. I can hardly imagine someone depends on this particular error.