Suggested addition to versioning capabilities

Elastic Stack Elasticsearch
1

I'm currently writing a system that can have potentially high contention on a single item and I would like to ensure that the version with the greatest number (version number dictated by another process) is the one that is retained after the contention, even if the save attempts are not in numerical order.

If I have an existing item and I save the following versions:

4
3
7
5
6

Then I would like 7 to be the version that is retained.

The principle is that if ES receives a version number greater than the current expected ID then skip any that were missed. If it receives a version number less than the current expected ID then ignore it.

There may already be a way to achieve this functionality that I have overlooked, but if not then I would be very appreciative of its inclusion.

Thanks,
Marcus

2

Hi Marcus,

it is exactly how versioning work in ES.

Quoted from http://www.elasticsearch.org/guide/reference/api/index_.html:

the system checks to see if the version number passed to the index request
is greater than or equal to the version of the currently stored document.
If true, the document will be indexed and the new version number used. If
the value provided is lower than the stored document’s version number, a
version conflict will occur and the index operation will fail.

A nice side effect is that there is no need to maintain strict ordering of
async indexing operations executed a result of changes to a source
database, as long as version numbers from the source database are used.

3

On Sat, 2011-11-05 at 03:38 -0700, MarcusLongmuir wrote:

I'm currently writing a system that can have potentially high contention on a
single item and I would like to ensure that the version with the greatest
number (version number dictated by another process) is the one that is
retained after the contention, even if the save attempts are not in
numerical order.

Use version_type=external:

curl -XPUT 'http://127.0.0.1:9200/foo/bar/1?pretty=1&version=10&version_type=external' -d '
{
"foo" : "bar"
}
'

clint

4

Hi Benjamin

A nice side effect is that there is no need to maintain strict
ordering of async indexing operations executed a result of changes to
a source database, as long as version numbers from the source database
are used.

Note "as long as version numbers from the source database are used"

In other words, if you don't specify version_type=external, then
out-of-sync versions will fail

clint