PaperTrail 版本控制中的 STI 模型双重记录问题分析

问题背景

在 Ruby on Rails 项目中，PaperTrail 是一个非常流行的版本控制 gem，它能够记录 ActiveRecord 模型的变更历史。然而，当与 Rails 的单表继承（STI）功能结合使用时，开发者可能会遇到一个特殊的问题：在 STI 模型中调用 has_paper_trail 会导致同一记录的变更被插入两次到 versions 表中。

问题重现

通过一个简单的测试用例可以清晰地重现这个问题：

class User < ActiveRecord::Base
  has_paper_trail
end

class Admin < User
  has_paper_trail on: [:create]
end

当创建 Admin 实例时，PaperTrail 会向 versions 表插入两条记录，而不是预期的一条记录。这是因为 PaperTrail 在父类 User 和子类 Admin 上都注册了回调。

技术原理

这个问题的根源在于 ActiveRecord 的回调继承机制和 PaperTrail 的实现方式：

1. 当在父类上调用 has_paper_trail 时，PaperTrail 会为该类注册一系列回调
2. 当子类继承父类时，这些回调也会被继承
3. 如果在子类上再次调用 has_paper_trail，会注册另一组相同的回调
4. 结果就是同一个操作会触发两次版本记录

解决方案

目前有三种可行的解决方案：

1. 条件检查：在调用 has_paper_trail 前检查是否已经设置过

other.has_paper_trail unless other.respond_to?(:paper_trail_options)

2. 统一配置：只在基类上调用 has_paper_trail，子类继承配置

3. 使用 PR 修复：等待并应用官方提供的修复补丁

最佳实践

对于使用 STI 的项目，建议采用以下模式：

class ApplicationRecord < ActiveRecord::Base
  NON_VERSIONED_MODELS = %w[SomeModel AnotherModel]
  
  def self.inherited(other)
    super
    return if NON_VERSIONED_MODELS.include?(other.name)
    
    unless other.respond_to?(:paper_trail_options)
      other.has_paper_trail
    end
  end
end

总结

PaperTrail 在处理 STI 模型时的双重记录问题是一个典型的回调继承问题。理解这个问题的本质有助于开发者在使用版本控制功能时做出更合理的设计决策。目前可以通过条件检查来规避这个问题，未来版本的 PaperTrail 可能会内置解决这个问题的机制。