# ElasticSearch document versioning **URL:** \ **Category:** Elasticsearch\ **Created:** [March 3, 2014, 2:51pm UTC](https://discuss.elastic.co/t/elasticsearch-document-versioning/16110 "2014-03-03T14:51:21Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![janosz\_krzysztof](https://avatars.discourse-cdn.com/v4/letter/j/97f17d/32.png) [@janosz\_krzysztof](https://discuss.elastic.co/u/janosz_krzysztof)\ **Post date:** [March 3, 2014, 2:51pm UTC](https://discuss.elastic.co/t/elasticsearch-document-versioning/16110/1 "2014-03-03T14:51:21Z")
Hello, I have a question if it's possible to replace the document with same version? The reason why I'm trying to do it, is situation such that: - inserting new doc with external version - let's say that this document has been noticed to be corrupted in some way - we want to replace it, but keep same version as it was, because it's external I know that I can remove it and insert it again with given version, but this is not atomic operation. So are they any other ways that guarantees atomic update in such situation? Thanks in advance, Krzysztof Janosz -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/3243d650-4a2c-4880-8dc1-e8d131536558%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/3243d650-4a2c-4880-8dc1-e8d131536558%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Binh\_Ly\_2](https://avatars.discourse-cdn.com/v4/letter/b/d07c76/32.png) [@Binh\_Ly\_2](https://discuss.elastic.co/u/Binh_Ly_2)\ **Post date:** [March 3, 2014, 7:49pm UTC](https://discuss.elastic.co/t/elasticsearch-document-versioning/16110/2 "2014-03-03T19:49:31Z")
Unfortunately you can't do this if you're using external versioning. I would just up the version of the external source and then use that to replace the indexed doc. Also keep in mind that if you delete a doc, you cannot "immediately" index a new similar or lower versioned doc to replace it. You'd have to wait 60 seconds to be able to "replace" it. Just FYI. -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/7406f34c-b8f4-4621-9923-b310ebdd3fc0%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/7406f34c-b8f4-4621-9923-b310ebdd3fc0%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![janosz\_krzysztof](https://avatars.discourse-cdn.com/v4/letter/j/97f17d/32.png) [@janosz\_krzysztof](https://discuss.elastic.co/u/janosz_krzysztof)\ **Post date:** [March 6, 2014, 11:14am UTC](https://discuss.elastic.co/t/elasticsearch-document-versioning/16110/3 "2014-03-06T11:14:05Z")
Thank you for your response. I've looked into source code of elasticsearch and it seems that change in VersionType.EXTERNAL (or creating new similar one): public boolean isVersionConflict(long currentVersion, longexpectedVersion ) { return currentVersion != Versions.NOT\_SET && currentVersion != Versions.NOT\_FOUND && (expectedVersion == Versions.MATCH\_ANY ||currentVersion > = expectedVersion); > } > to ``` public boolean isVersionConflict(long currentVersion, longexpectedVersion ``` ) { return currentVersion != Versions.NOT\_SET && currentVersion != Versions.NOT\_FOUND && (expectedVersion == Versions.MATCH\_ANY ||currentVersion > expectedVersion); > } > allows to set external version ID same as previous. (or at least, allows it > in simple test case ;)) > Is it so simple or does this carry some additional danger I can't catch at > the moment? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/a5d723cc-6e90-47df-8950-94ea04597a77%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/a5d723cc-6e90-47df-8950-94ea04597a77%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [March 6, 2014, 11:19am UTC](https://discuss.elastic.co/t/elasticsearch-document-versioning/16110/4 "2014-03-06T11:19:13Z")
With that change, you would open the door to hell 😉 Version conflicts must arise if there is more than one request with the same version. Jörg On Thu, Mar 6, 2014 at 12:14 PM, [janosz.krzysztof@gmail.com](mailto:janosz.krzysztof@gmail.com) wrote: > Thank you for your response. > > I've looked into source code of elasticsearch and it seems that change in > VersionType.EXTERNAL (or creating new similar one): > public boolean isVersionConflict(long currentVersion, longexpectedVersion > ) { > return currentVersion != Versions.NOT\_SET && currentVersion != > Versions.NOT\_FOUND > && (expectedVersion == Versions.MATCH\_ANY ||currentVersion > > > = expectedVersion); > > } > > to > > ``` > public boolean isVersionConflict(long currentVersion, longexpectedVersion > > ``` > > ) { > return currentVersion != Versions.NOT\_SET && currentVersion != > Versions.NOT\_FOUND > && (expectedVersion == Versions.MATCH\_ANY ||currentVersion > > > expectedVersion); > > } > > allows to set external version ID same as previous. (or at least, allows > > it in simple test case ;)) > > Is it so simple or does this carry some additional danger I can't catch at > > the moment? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFC55BsVEWkLehxAaoh6WYDvxKjvdCvRqWZWPCuwfB2BQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFC55BsVEWkLehxAaoh6WYDvxKjvdCvRqWZWPCuwfB2BQ%40mail.gmail.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![janosz\_krzysztof](https://avatars.discourse-cdn.com/v4/letter/j/97f17d/32.png) [@janosz\_krzysztof](https://discuss.elastic.co/u/janosz_krzysztof)\ **Post date:** [March 6, 2014, 11:36am UTC](https://discuss.elastic.co/t/elasticsearch-document-versioning/16110/5 "2014-03-06T11:36:13Z")
Hmm, sorry I was not precise enough - I mean, not resolving version conflicts with that way at every insert, but let's say creating some force mode, which would be only used in case described in my first post and assuming that this force mode is used only in "proper way" - e.g we ensure that at given point in time only one request with such update will come to es. Is this still creating problem, e. g. such data when updated in described "force mode" would not be propagated to other nodes resulting in data incosistency? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/ac0f4433-9560-42a1-8745-4aae14d82f1b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/ac0f4433-9560-42a1-8745-4aae14d82f1b%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [March 6, 2014, 11:58am UTC](https://discuss.elastic.co/t/elasticsearch-document-versioning/16110/6 "2014-03-06T11:58:54Z")
I think you misunderstand the versioning concept in MVCC. In ES, it only looks like ES docs are attached with a version and smart client might be capable of "superseding" versioning at will. But the concept is that versions are attached within a read/write cycle to a client that is dealing with the doc. It is the client that must be absolutely sure that the writing is "valid" - new data is written according to the version that was read before. Keeping the same version means, the document read/write cycle is not corrupted. So if you suggest a "force mode", you disable this causality. Other clients read a version, then a "force mode" client touches the doc, but the version stays the same. All other clients that had read the old version are messed up, they can no longer trust the versioning, or the data they read, or both. So, if you don't want MVCC, you should just ignore versioning in your concept... Jörg On Thu, Mar 6, 2014 at 12:36 PM, [janosz.krzysztof@gmail.com](mailto:janosz.krzysztof@gmail.com) wrote: > Hmm, sorry I was not precise enough - I mean, not resolving version > conflicts with that way at every insert, but let's say creating some force > mode, which would be only used in case described in my first post and > assuming that this force mode is used only in "proper way" - e.g we ensure > that at given point in time only one request with such update will come to > es. Is this still creating problem, e. g. such data when updated in > described "force mode" would not be propagated to other nodes resulting in > data incosistency? > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/ac0f4433-9560-42a1-8745-4aae14d82f1b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/ac0f4433-9560-42a1-8745-4aae14d82f1b%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/ac0f4433-9560-42a1-8745-4aae14d82f1b%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/ac0f4433-9560-42a1-8745-4aae14d82f1b%40googlegroups.com?utm_medium=email&utm_source=footer) > . > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEUUvn3ZCJs2Jpr0axvrnmG\_72zosAZ59FWPthMtumDUQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEUUvn3ZCJs2Jpr0axvrnmG_72zosAZ59FWPthMtumDUQ%40mail.gmail.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:45am UTC](https://discuss.elastic.co/t/elasticsearch-document-versioning/16110/7 "2017-07-06T01:45:21Z")