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
Some options, in descending order of recommendation (most highly recommended first):
version_limit(Supported) - Save disk space instead by limiting the number of versions you create for a given record, using
object_changescolumn. Precludes the tracking of associations (
recordable_object_changes, method 1 (Not supported) - Custom version model, but still using the
#paper_trailto return a custom child class of
RecordTrail#recordable_object_changes. Overriding these methods breaks your warranty.
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.
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.