Description
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.
Attachments
Issue Links
- relates to
-
TINKERPOP-1616 Strengthen semantics around lazy iteration and graph modifications
-
- Closed
-
- links to
