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

stephen mallette reassigned TINKERPOP-1685:
-------------------------------------------

         Assignee: stephen mallette
    Fix Version/s: 3.4.0

I think that this is best implemented with a new {{Graph.Feature}} which will 
leave it up to graph providers to decide how to their insert/update semantics 
work. In this way, we don't have to do anything special to our APIs. 

> Introduce optional feature to allow for upserts without read-before-write
> -------------------------------------------------------------------------
>
>                 Key: TINKERPOP-1685
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1685
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: structure
>    Affects Versions: 3.2.4
>            Reporter: Jeremy Hanna
>            Assignee: stephen mallette
>            Priority: Major
>             Fix For: 3.4.0
>
>
> Currently TINKERPOP-479 is being considered to do some sort of 
> {{getOrCreate}} functionality.  However for some data stores such as 
> Cassandra, this is still short of upserts.  As I understand it, 
> {{getOrCreate}} still has to do a read-before-write.  In cases where the user 
> can guarantee that upserts are going to be idempotent, there is a significant 
> performance improvement and risk avoidance (race condition with 
> multi-threaded read-before-write).  Additionally with some data stores such 
> as Apache Cassandra, the natural way to update data is with an upsert.
> This ticket is to consider adding an additional optional feature to support 
> upserts by default on {{addV}} and {{addE}}.  It could be called something 
> like {{upsert_on_add}}.  This configuration would default to false so that it 
> doesn't break anyone currently relying on errors when adding the same vertex 
> or edge.  However if enabled, it would just add or modify data on the 
> existing vertex or edge.
> If overriding the existing {{addV}} and {{addE}} operations with this 
> optional feature is undesirable, then perhaps new operators could be added 
> like {{upsertV}} and {{upsertE}} or {{putV}} and {{putE}} and those could be 
> used to both add and update the data.  Allowing it to insert data is 
> important because otherwise you are left with having to read-before-write 
> which incurs the performance cost and race condition risk.  A benefit of a 
> separate operator is that you could mix upsert behavior and non-upsert add 
> behavior in a single graph.  I'm not sure there is a huge need to use both in 
> a single graph, but it is a difference between the two strategies.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to