这有点与
#837相关,因为我的模型上有一个大数据列,但是我觉得我可能会更好地服务于该问题中提出的相反 – 即维护对象列而不是object_changes列.

我们一直在运行没有versions.object_changes列.现在我已经添加了这一列,我意识到我正在编写很多我不关心object_changes中数据列的数据 – 因为对数据的微小改变会导致它被有效地写入版本3x(一次进入对象和对象之前和之后两次的对象).

我不认为跳过或忽略是我想要的,因为我确实希望对数据进行更改以生成新版本.

我应该沿着自定义版本模型路线走下去吗？或者你推荐什么？

最佳答案 一些选项,按推荐的降序排列(最强烈推荐的第一个)：

> version_limit(支持) – 使用version_limit限制为给定记录创建的版本数,从而节省磁盘空间. (https://github.com/airblade/paper_trail#2e-limiting-the-number-of-versions-created)
>自定义表(支持) – 自定义版本模型,没有object_changes列的自定义表.排除实验关联功能(track_associations必须为false [默认])
> Patch recordable_object_changes,方法1(不支持) – 自定义版本模型,但仍使用版本表.覆盖#paper_trail以返回RecordTrail的自定义子类,该子类重写RecordTrail#recordable_object_changes.覆盖这些方法会破坏您的保修.
> Patch recordable_object_changes,方法2(不支持) – 覆盖RecordTrail#recordable_object_changes,添加一个类检查条件.除了你要破解的模型之外,为所有人打电话.覆盖此方法会破坏您的保修.
>自定义序列化程序(支持,但不适用于此) – 带有类检查条件的自定义序列化程序,以及一些告诉您是否序列化object_changes而不是对象的方法.可能是一个坏主意,似乎真的很hacky.

最后,我很乐意回顾一个增加新功能的PR,能够在每个模型的基础上配置哪些数据应该写入object_changes列.如果你真的想要做到这一点,并看到它完成,请打开一个新的问题,以便我们进一步讨论.有一些不同的设计可以工作.