[
https://issues.apache.org/jira/browse/TINKERPOP-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470978#comment-16470978
]
ASF GitHub Bot commented on TINKERPOP-1685:
-------------------------------------------
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/863
VOTE: +1
> 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)
