Gabe Kopley Gabe Kopley - 6 months ago 33
Ruby Question

Using PaperTrail, can I opt out of `object_changes` for a particular model or atttribute?

This is somewhat related to #837 in that I have a large data column on my models, however I think I may be better served by the opposite of what's proposed in that issue - that is, to maintain the object column but not the object_changes column.

We had been running with no versions.object_changes column. Now that I've added this column, I realized I am writing a lot of data I don't care about for the data column in object_changes - since a tiny change to data causes it to be written out to versions effectively 3x (once in

and twice in
for the before and after).

I don't think skip or ignore is what I want, because I would indeed like the changes to data to produce a new version.

Should I go down the custom version model route? Or what do you recommend?


Some options, in descending order of recommendation (most highly recommended first):

  1. version_limit (Supported) - Save disk space instead by limiting the number of versions you create for a given record, using version_limit. (
  2. Custom table (Supported) - Custom version model, custom table without object_changes column. Precludes the tracking of associations (track_associations must be false)
  3. Patch recordable_object_changes, method 1 (Not supported) - Custom version model, but still using the versions table. Override #paper_trail to return a custom child class of RecordTrail which overrides RecordTrail#recordable_object_changes. Overriding these methods breaks your warranty.
  4. Patch recordable_object_changes, method 2 (Not supported) - Override RecordTrail#recordable_object_changes, adding a class-check conditional. Call super for all but the model you want to hack. Overriding this method breaks your warranty.
  5. Custom serializer (Supported, but not for this) - Custom serializer with class-check conditional, and some way of telling whether you're serializing object_changes and not object. Probably a bad idea, seems really hacky.

Finally, I'd be happy to review a PR that adds a new feature, the ability to configure, on a per-model basis, which data should be written to the object_changes column. If you're serious about working on that, and seeing it through to the finish, please open a new issue so we can discuss it further. There are a few different designs that could work.