Hi,
I'm trying to figure out what the behavior of version numbers is on
deletes.
We have a test environment where data is copied from a production database
regularly, so we want:
Document copied into test environment, version 1, indexed into ES.
Updatedin test environment, version 2, indexed
…
Document refreshed from production environment, back to version 1.
We want this then to be reindexed, so we try deleting that document, then
reindexing it, but get a version conflict exception with current version 2,
provided 2.
It looks like the delete request is incrementing the (VersionType.EXTERNAL)
version number.
Is this correct, and if so is there a way to delete a document and reset
the version number (without deleting the whole index)?
We ran into a similar issue. The trick is looking at the code that you have
to provide the original version # in the delete call as well otherwise the
delete triggers the default internal versioning behavior and increments the
number.
Maybe try a GET on the item to get the current version before a delete
(hard for bulk though mate with multi get and bulk delete it might perform
ok)
Paul
On Wednesday, 13 June 2012, Davie Moston wrote:
Hi,
I'm trying to figure out what the behavior of version numbers is on
deletes.
We have a test environment where data is copied from a production database
regularly, so we want:
Document copied into test environment, version 1, indexed into ES.
Updatedin test environment, version 2, indexed
…
Document refreshed from production environment, back to version 1.
We want this then to be reindexed, so we try deleting that document, then
reindexing it, but get a version conflict exception with current version 2,
provided 2.
It looks like the delete request is incrementing the
(VersionType.EXTERNAL) version number.
Is this correct, and if so is there a way to delete a document and reset
the version number (without deleting the whole index)?
I've tried setting the version number in the delete call, but this seems to result in the delete failing with version conflict exception if the version number is less or equal to the current version in ES.
It only succeeds if the version number is higher, which makes sense for optimistic locking, but I want to delete all knowledge of this document and start again.
Is there a way to delete and reset the version number for an id?
We ran into a similar issue. The trick is looking at the code that you have
to provide the original version # in the delete call as well otherwise the
delete triggers the default internal versioning behavior and increments the
number.
Maybe try a GET on the item to get the current version before a delete
(hard for bulk though mate with multi get and bulk delete it might perform
ok)
Paul
On Wednesday, 13 June 2012, Davie Moston wrote:
Hi,
I'm trying to figure out what the behavior of version numbers is on
deletes.
We have a test environment where data is copied from a production database
regularly, so we want:
Document copied into test environment, version 1, indexed into ES.
Updatedin test environment, version 2, indexed
…
Document refreshed from production environment, back to version 1.
We want this then to be reindexed, so we try deleting that document, then
reindexing it, but get a version conflict exception with current version 2,
provided 2.
It looks like the delete request is incrementing the
(VersionType.EXTERNAL) version number.
Is this correct, and if so is there a way to delete a document and reset
the version number (without deleting the whole index)?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.