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?

Gorden

How flexible is your schema? Could you move those attributes into another model? – Operant

This attribute, no - it's actually this data attribute that I am most interested in versioning - I just don't want the diffs. – Gorden

I also didn't see anyway in papertrail to do this. Its either skip, or ignore. You could fork the gem and see if you can add configuration that would do what you want. – Operant

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.

Caudle