我的问题是:我应该使用我自己的模型版本控制还是使用已经存在的版本控制宝石之一?如果我应该使用一个宝石，哪一个似乎最适合这个应用程序?
关于我的应用的信息
我的应用程序是一个简单的清单应用程序。有清单和工作，我跟踪用户的响应响应和提交。Response告诉我用户说了什么("完成了"，并附有"我们需要更多拖把"的注释)，Submission告诉我特定的清单何时被填写(因为对于给定的清单可能有许多提交和响应集)。我将在下面展示我的关联，如果有帮助的话。
#checklist.rb
class Checklist < ActiveRecord::Base
has_many :jobs, :through => :checklists_jobs
has_many :submissions
end
#job.rb
class Job < ActiveRecord::Base
has_many :checklists, :through => :checklists_jobs
has_many :responses
end
#response.rb
class Response < ActiveRecord::Base
belongs_to :job
belongs_to :submission
belongs_to :user
end
#submission.rb
class Submission < ActiveRecord::Base
belongs_to :user
belongs_to :checklist
has_many :responses
end
我想做的是版本控制
我想做的是在检查表上记录用户对作业的反应。但是我想确保，如果检查表发生变化，我可以重新生成原始检查表(包含响应信息)。例如，我想确保我可以回答所有以前版本的检查表的这个问题:
"清单是什么样子的?三个星期二前的反应是什么?"
如果我更改检查表或它的任何工作，我不想丢失这个问题的答案。
我认为最好的方法是使用版本控制(对于作业和检查表)。例如，如果管理员更改了作业(名称或描述)，那么我不会更新现有的作业，而是创建一个新版本并保持旧版本不变。然后我就把旧的东西留在原地，把清单指向新版本的工作。
我应该使用gem还是自己滚动?
我想决定的是我是否应该只是滚动我自己的(编写代码来增加版本，将所有内容指向版本，并保留以前的版本)或使用现有的解决方案。两个最好的解决方案似乎是paper_trail和vestal_versions。我没有足够的声望点来发布两个以上的链接，所以我将链接到每个宝石的Railscast(如果你想的话，这将让你到宝石本身)。Railscast 255撤销与paper_trail和Railscast 177模型版本控制- 177使用vestal_versions.
自己动手的优点:
- 我需要通过重建清单来报告所有历史数据以及他们的反应。这是应用程序的一个主要功能，看起来对于我提到的宝石，这将是一个棘手的问题。 我就可以报告了关于版本组("我想看到任何版本的所有回复")。这样似乎很容易。
自己滚动的缺点:
- 这将是棘手的，因为我有几个has_many:through关联。我必须非常小心地更新所有表并正确地连接表。(这也可能是一个宝石的问题)
- 由于我使用此版本数据进行报告，我担心性能问题。解析哈希似乎在计算上很昂贵，而依赖带索引的平面表似乎相当高效。
- 这两个gem似乎更适合于保存版本历史以进行跟踪，而不是真正用于维护历史信息以报告目的。
这似乎很重要，因为无论我做什么决定，我基本上都会坚持下去。我认为以后从一种方法切换到另一种方法并不容易。
使用PaperTrail，不要推出自己的解决方案。我强烈反对理查德的回答。PaperTrail是一个非常活跃的项目，很多人都在修复bug，支持最新的Rails和Ruby版本，并处理gem冲突。
如果你不喜欢PaperTrail做某事的方式，你应该分叉它并改变这种行为。如果它是一个普遍的改进，提交一个pull请求，这样我们都可以从你的工作中受益。不要从头开始重写，因为您没有PaperTrail提交者已经经历过的错误和边缘案例的后见之见。
我的经验是，当你问自己制定解决方案还是使用第三方解决方案时，答案几乎总是"自己动手"。你不仅可以在功能方面做出你想要的东西，你也不必受制于其他开发人员:
- 修复bug
- 支持最新rails更新/ruby更新等
- 不会以你无法解决的微妙方式与你的应用发生冲突(需要不同版本的依赖gem)。
我说如果你有能力，你应该花时间写你想写的东西。两年后你会有大回报的。