[jira] [Comment Edited] (TINKERPOP3-479) Consider Providing "getOrCreate" Functionality

["Curtis Allen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP3-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14388816#comment-14388816 ] 

Curtis Allen edited comment on TINKERPOP3-479 at 3/31/15 4:58 PM:
------------------------------------------------------------------

Thanks Matt,
True some use cases wouldn't care if the Vertex was created or not. However the {{ensure}} method is going to have to check for vertex existence even if it doesn't return a {{created}} property, {{ensure}} inherently will require queries of distributed state how else would it know to create the vertex or return a found vertex? 

I'd argue that regardless of {{ensure}} or {{ensureBlind}} the method will have to pay the cost of reading before writing which can be an anti pattern on distributed backends like Cassandra. Unless I'm missing something here. 

UPDATE:
I guess with cql 3 you can actually upsert http://beckje01.com/blog/2014/08/13/cassandra-upsert-everything/
Titan backed by Cassandra could possibly use a similar approach on {{ensureBlind}} to Matt's point. 
The {{ensure}} method would incur more of a cost because it would have to check if the vertex existed before inserting. 
So it looks like the two methods {{ensure}} and {{ensureBlind}} would have a different performance cost.


was (Author: curtissallen):
Thanks Matt,
True some use cases wouldn't care if the Vertex was created or not. However the {{ensure}} method is going to have to check for vertex existence even if it doesn't return a {{created}} property, {{ensure}} inherently will require queries of distributed state how else would it know to create the vertex or return a found vertex? 

I'd argue that regardless of {{ensure}} or {{ensureBlind}} the method will have to pay the cost of reading before writing which can be an anti pattern on distributed backends like Cassandra. Unless I'm missing something here. 

> Consider Providing "getOrCreate" Functionality
> ----------------------------------------------
>
>                 Key: TINKERPOP3-479
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-479
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: structure
>            Reporter: stephen mallette
>
> One of the most commonly written functions used is good ol' "getOrCreate" where you want to get a {{Vertex}} if it exists or create it with supplied properties if it does not.  We currently have a "helper" function for this on {{ElementHelper}} 
> https://github.com/tinkerpop/tinkerpop3/blob/6d0f00865f673cb0739f6f310e1868425f732924/gremlin-core/src/main/java/com/tinkerpop/gremlin/structure/util/ElementHelper.java#L62
> but perhaps it is time to treat this issue as a first class citizen as part of the Graph API.  I think that some vendors might actually be able to optimize this function as well.  
> Another aspect of "getOrCreate" is "upsert" as well as options to ensure uniqueness.  All of these things we've at some point or another built variations of outside of TinkerPop for applications, data loading, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)