使用PaperTrail，我可以选择退出特定模型或atttribute的`object_changes`吗？

Question

这与#837有些相关，因为我在模型上有一个大的数据列，但是我认为我可能会更好地服务于与该问题相反的建议 - 也就是维护对象列而不是object_changes柱。

我们一直运行没有versions.object_changes列。现在我已经添加了这个列，我意识到我正在编写大量数据，我不关心object_changes中的数据列 - 因为对数据的微小更改导致它被有效地写入版本3x（一次object，前两次为object_changes）。

我不认为跳过或忽略是我想要的，因为我确实希望更改数据来生成新版本。

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

Answer 1

一些选项，在降推荐的顺序（最强烈推荐在前）：

1. version_limit（支持） - 通过而不是限制你创建一个给定记录版本数量，使用节省磁盘空间version_limit。 （https://github.com/airblade/paper_trail#2e-limiting-the-number-of-versions-created）
2. 定制表格（支持） - 定制版本型号，不包含object_changes列的定制表格。排除了实验协会功能（track_associations必须false [默认]）
3. 补丁recordable_object_changes，方法1（不支持） - 定制版车型，但仍然使用versions表。覆盖#paper_trail以返回覆盖RecordTrail#recordable_object_changes的自定义子类RecordTrail。重写这些方法会破坏您的保修。
4. 修补程序recordable_object_changes，方法2（不支持） - 覆盖RecordTrail#recordable_object_changes，添加一个类检查条件。除了你想要破解的模型之外，请为所有人打电话。重写此方法会破坏保修。
5. 自定义序列化程序（支持，但不是为此） - 自定义序列化程序与类检查条件，并告诉你是否序列化object_changes而不是object。可能是一个糟糕的主意，看起来真的很黑。

最后，我很乐意回顾增加一项新功能的PR，能够根据每个型号配置哪些数据应写入object_changes列。如果你认真对待这个问题，并看到它完成，请开一个新的问题，以便我们可以进一步讨论。有几种不同的设计可以工作。