【发布时间】：2013-03-05 22:38:14
【问题描述】：
我的问题：我应该推出自己的模型版本控制还是使用已经存在的版本控制 gem 之一？如果我应该使用 gem，哪一个似乎最适合这个应用程序？
关于我的应用的信息
我的应用是一个简单的清单应用。有清单和工作，我使用响应和提交来跟踪用户响应。响应告诉我使用说什么（“完成”，附注“我们需要更多拖把。”），提交告诉我该特定清单何时填写（因为可能有许多提交和给定的响应集清单）。如果有帮助，我将在下面显示我的关联。
#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
我想用版本控制做什么
我想做的是记录用户对清单上的工作的反应。但我想确保如果清单发生更改，我可以重现原始清单（带有响应信息）。例如，我想确保我可以为所有以前版本的清单回答这个问题：
“清单是什么样的，三个星期二前的反应是什么？”
如果我更改清单或其任何工作，我不想失去该问题的答案。
我认为最好的方法是使用版本控制（用于作业和清单）。例如，如果管理员更改了作业（名称或描述），那么我不会更新现有作业，而是创建一个新版本并保持旧版本不变。然后我就把旧的东西留在原地，把清单指向工作的新版本。
我应该使用宝石还是自己滚动？
我要决定是自己动手（编写代码以增加版本，将所有内容指向版本，并保留以前的版本）还是使用现有的解决方案。两个最好的解决方案似乎是paper_trail 和vestal_versions。我没有足够的声望点来发布两个以上的链接，所以我将链接到 gem 的每个 Railscast（如果你愿意，它会让你到 gem 本身）。 Railscast 255 Undo with paper_trail 和 Railscast 177 Model Versioning - 177 使用了vestal_versions。
自己动手的优点：
- 我需要通过重建清单来报告所有历史数据 以及他们的回应。这是该应用程序的主要功能。这好像是 这对于我提到的宝石来说会很棘手。
- 我可以报告 关于版本组（“我想查看任何版本的所有回复 这份工作”）。这样看来很容易。
自己滚动的缺点：
- 这会很棘手，因为我有几个 has_many :through 关联。我必须非常小心地更新所有表并正确连接表。 （这也可能是其中一颗宝石的问题）。
- 由于我使用此版本数据进行报告，因此我担心性能问题。解析散列的计算成本似乎很高，而依赖带有索引的平面表似乎非常有效。
- 这两个 gem 似乎更适合保留版本历史以供跟踪，而不是真正用于维护历史信息以进行报告。
这似乎很重要，因为无论我决定什么，我基本上都会坚持下去。我认为以后从一种方法切换到另一种方法并不容易。
【问题讨论】：
标签： ruby-on-rails-3.2 gem database-versioning paper-trail-gem vestal-versions