Rails 3.2 app - 我应该使用版本控制宝石(paper_trail或vestal_versions)还是手动处理它？

Question

我的问题:我应该推出自己的模型版本还是使用其中一个已经存在的版本化宝石？如果我应该使用宝石,哪一个最适合这个应用？

关于我的应用的信息

我的应用程序是一个简单的清单应用程序 有清单和工作,我跟踪响应和提交的用户响应.响应告诉我使用说的是什么("完成",注意"我们需要更多的拖把.")并且提交告诉我何时填写了特定的清单(因为给定的清单可能有很多提交和答复)清单).我会在下面展示我的协会,以防万一.

#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本身).使用paper_trail和Railscast进行Railscast 255撤消和模型版本控制 - 177使用vestal_versions.

推销自己的优点:

• 我需要通过重建清单及其回复来报告所有历史数据.这是该应用程序的主要功能.对于我提到的宝石,这似乎很棘手.
• 我将能够报告版本组("我想查看该作业的任何版本的所有回复").这似乎很容易.

我要自己动手:

• 这将是棘手的,因为我有几个has_many:通过关联.我必须非常小心地更新所有表并正确连接表.(这也可能是其中一个宝石的问题).
• 由于我使用此版本数据进行报告,因此我担心性能问题.解析哈希似乎计算成本很高,而依赖带索引的平面表似乎非常有效.
• 这两种宝石似乎更适合保留跟踪的版本历史记录,而不是真正用于维护历史信息以用于报告目的.

这看起来很重要,因为不管我决定我基本上都会被困住.我认为以后从一种方法切换到另一种方法并不容易.

Answer 1

使用PaperTrail,不要推出自己的解决方案.我非常不同意理查德的回答.PaperTrail是一个非常活跃的项目,许多人为错误修复做出贡献,支持最新的Rails和Ruby版本,以及处理gem冲突.

如果你不喜欢PaperTrail做某事的方式,你应该分叉它并改变那种行为.如果这是一般性改进,请提交拉取请求,以便我们都可以从您的工作中受益.不要从头开始重写它,因为您没有PaperTrail提交者已经完成的错误和边缘情况的后见之明.

Answer 2

我的经验是，当您问有关制定自己的解决方案还是使用第三方解决方案的问题时，答案几乎总是“自己动手”。您不仅可以在功能方面完全满足您的需求，而且无需依赖其他开发人员：

1. 修复他们的错误
2. 支持最新的rails更新/ruby更新等
3. 不会以某种您无法解决的微妙方式与您的应用程序发生冲突（需要不同版本的依赖 gem）。

我说如果你有能力就应该花时间写你想要的东西。两年后它将获得巨大回报。