Skip excess cloning of JSONized object_changes

[stokarenko]

Every clone-like operation over the object_changes column will allocate the O(n) of RAM, where n is a kind of complexity of object model in general and applied changes in particular.

Lets skip excess object_changes.to_hash call when the object_changes is a kind of json column.

• Wrote good commit messages.
• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Added an entry to the Changelog if the new
  code introduces user-observable changes.
• The PR relates to only one subject with a clear title
  and description in grammatically correct, complete sentences.

[jaredbeck]

Somehow, this makes more sense to me when I see it as a separate PR. Looks good, I'm just going to add some comments.

[jaredbeck]

Hmm this may be a breaking change, I'm not sure.

Until now, we have passed a plain Hash to object_changes_adapter.diff. This PR would change that part of our public API, passing a HashWithIndifferentAccess instead.

However, I think this change would not affect the reference implementation of object_changes_adapter.

What do you think? Should we treat this as a breaking change?

[jaredbeck]

I've added some comments, and fixed the object_changes_adapter API. Please review.

[stokarenko]

I feel that change from HashWithIndifferentAccess to pure Hash can be a breaking one, but not vice versa..

On the other hand I'm able to think up some dummy object_changes_adapter implementation which will be sensitive to PR.

Looks like it's better to mark the change as rarely breaking, to be honest with consumers..

[jaredbeck]

Looks like it's better to mark the change as rarely breaking, to be honest with consumers..

Please see 309a8c1, in which I preserve the public API by using .to_hash.

-         changes = PaperTrail.config.object_changes_adapter.diff(changes)
+         changes = PaperTrail.config.object_changes_adapter.diff(changes.to_hash)

What do you think?

[stokarenko]

I've added some comments, and fixed the object_changes_adapter API. Please review.

LGTM! Now there is no any chance to break the things for consumers :)