ruby-on-rails - 通过Tire gem进行Elasticsearch版本控制

Question

我有一个现有的Rails应用程序，该应用程序使用轮胎(0.4.0)与Elasticsearch(0.17.4)引擎进行交互。它已经有一些使用Tire::Persistence的模型。我想添加一个利用Elasticsearch版本控制的新模型，以跟踪所有更改并能够还原到以前的版本。

现在，当我检索任何“持久”模型实例时，我检查_version，它始终是nil。我尚未找到任何与版本控制相关的轮胎文档。我必须以某种方式激活它，还是手动保存带有版本值的记录？我在这里是否正确？

我确实看到某些方法返回项目的_version值，但其他方法没有...

Article.first._version                          # => nil
Article.search("sample query").first._version   # => nil
Article.find("id_123")._version                 # => 8

同样，版本控制似乎增加了2。也许轮胎没有完全具备处理版本控制的能力。是否保存以前的版本？如何检索记录的先前版本？

[编辑]我可能误解了Elasticsearch中实际上是什么“版本化”。似乎主要用于并发控制。天哪(不过，我想听听其他情况)

Answer 1

首先，是的，是的，正如您在“编辑”中编写的那样，ElasticSearch中的版本并不是要存储文档的修订版本，而是为了并发控制(例如，不使用陈旧的版本覆盖文档)。

其次，您必须声明要从搜索返回的版本。 http://www.elasticsearch.org/guide/reference/api/search/version.html

这段代码向您展示了如何在Tire中进行操作。

require 'tire'

Tire.index('articles') do
  delete
  create
  store id: 1, title: 'One'
  store id: 2, title: 'Two'
  store id: 2, title: 'Two again'

  refresh
end

articles = Tire.search('articles') do
             query { all } 

             version true
           end.results

articles.each do |article|
  puts "Article '#{article.title}' has version #{article._version}"
end

目前，最好阅读Tyre集成测试套件以获取文档。文档当然是应该并且将会改进的东西。

至于您的原始需求本身，过去，CouchDB经常会出现类似的问题。 Simple Document Versioning with CouchDB博客文章描述了一种不错的策略。由于文档模型相似，因此对CouchDB解决方案的研究将对您有所帮助。 (当然，与ElasticSearch相反，CouchDB确实在物理上存储文档修订，因此打开了不同的策略范围。)

在ElasticSearch中，关于使用修订的基本决定是:

是否要直接将完整修订版本存储在JSON本身中？

对于较小的文档和较小的数据库，这可能是有意义的。根据您的要求，它可以使搜索历史文档变得非常简单。

ElasticSearch中的 Nested Type将使这些“作为嵌套文档的修订”的工作变得便捷。

(我敢打赌，您也可以只将文档的“差异”存储在JSON本身中，但这会给您的应用程序逻辑带来更大的压力。)

我想将修订存储为单独的文档吗？

您可能需要单独存储修订，然后将其与基础文档“链接”。 ElasticSearch中的 parent/child support使得处理这些关系和查询成为可能。