[ 
https://issues.apache.org/jira/browse/UNOMI-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noa updated UNOMI-345:
----------------------
    Description: 
Since updating events is now possible, there's a need to make sure that an 
event won't be updated with it's older version. e.g - when you creat an event:

{      "foo": "bar",     "version": 1 }

and then send an event update:

{      "foo": "baz",     "version": 2 }

You need to make sure that the older version, "bar", is saved *before* the 
update, or not saved at all, so eventually the document will contain the "baz".

Currently, there's no way of implementing that in Unomi, but Elasicsearch does 
have a solution for that. It's called external versioning. By default, 
Elasticsearch uses an internal documents versioning that increments the version 
+1 every document update. If you prefer managing your versions on your own,  
Elastic allows that by using external versioning - 

[https://www.elastic.co/blog/elasticsearch-versioning-support]

External versioning is the solution because Elasticsearch throws an exception 
(409) if you try to save a document with an older version than the one that is 
currently stored. This way, if we go back to our example, the "baz" will be 
saved first and when the "bar" will arrive it will be rejected because it's an 
older version.

 

 

  was:
Since updating events is now possible, there's a need to make sure that an 
event won't be updated with it's older version. e.g - when you created an event:
{
     "foo": "bar",
    "version": 1
}

and then sent an event update:
{
     "foo": "baz",
    "version": 2
}

You need to make sure that the older version, "bar", is saved *before* the 
update, or not saved at all, so eventually the document will contain the "baz".

Currently, there's no way of implementing that in Unomi, but Elasicsearch does 
have a solution for that. It's called external versioning. By default, 
Elasticsearch uses an internal documents versioning that increments the version 
+1 every document update. If you prefer managing your versions on your own,  
Elastic allows that by using external versioning - 

[https://www.elastic.co/blog/elasticsearch-versioning-support]

External versioning is the solution because Elasticsearch throws an exception 
(409) if you try to save a document with an older version then the one that is 
currently stored. This way, if we go back to our example, the "baz" will be 
saved first and when the "bar" will arrive it will be rejected because it's an 
older version.

 

 


> Support Elasticsearch external versioning
> -----------------------------------------
>
>                 Key: UNOMI-345
>                 URL: https://issues.apache.org/jira/browse/UNOMI-345
>             Project: Apache Unomi
>          Issue Type: New Feature
>          Components: core
>            Reporter: Noa
>            Priority: Major
>
> Since updating events is now possible, there's a need to make sure that an 
> event won't be updated with it's older version. e.g - when you creat an event:
> {      "foo": "bar",     "version": 1 }
> and then send an event update:
> {      "foo": "baz",     "version": 2 }
> You need to make sure that the older version, "bar", is saved *before* the 
> update, or not saved at all, so eventually the document will contain the 
> "baz".
> Currently, there's no way of implementing that in Unomi, but Elasicsearch 
> does have a solution for that. It's called external versioning. By default, 
> Elasticsearch uses an internal documents versioning that increments the 
> version +1 every document update. If you prefer managing your versions on 
> your own,  Elastic allows that by using external versioning - 
> [https://www.elastic.co/blog/elasticsearch-versioning-support]
> External versioning is the solution because Elasticsearch throws an exception 
> (409) if you try to save a document with an older version than the one that 
> is currently stored. This way, if we go back to our example, the "baz" will 
> be saved first and when the "bar" will arrive it will be rejected because 
> it's an older version.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to