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

Question

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 object and twice in object_changes 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?

Answer 1

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. (https://github.com/airblade/paper_trail#2e-limiting-the-number-of-versions-created)
2. Custom table (Supported) - Custom version model, custom table without object_changes column. Precludes the experimental associations feature (track_associations must be false [the default])
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.

Update, 2019: We now have object_changes_adapter It's only for expert users, and probably not my top recommendation.