Sorry, someone took out dev@ in the original email of my reply below.


> Begin forwarded message:
> From: Marko Rodriguez <>
> Subject: Re: [TinkerPop] gremlin-x
> Date: December 1, 2016 at 11:38:21 AM MST
> To:
> Hi,
>> One of the first reasons I came to graphs, Neo4j and then TinkerPop way
>> back was precisely because of the direct access to Node/Vertex. The user
>> treats it like any other object, not a remote connection. It is the
>> embedded nature that makes life so easy. In a way it was like having a
>> simplistic Hibernate as the core api. 99% of queries we write is to
>> retrieve vertices. Not Maps and Lists of something. TinkerPop's own test
>> suite applies this type of thinking. Querying/modifying Elements and
>> asserting them. Vertex and Edge abound as first class citizens.
> So Graph/Vertex/Edge/VertexProperty/Property will still exist for users as 
> objects in the respective GLV language, it is just they are not “attached” 
> and “rich.”
> For instance, in Gremlin-Python, you have:
> v = g.V().next()
> A ReferenceVertex contains the id of the vertex so you can always “re-attach” 
> it to the source.
> g.V(v).out()
>> Graph, Vertex and Edge is the primary abstraction that users deal with.
>> Having the direct representation of this is very very nice.
>> It makes user code easy and readable.  You know you are dealing with the
>> "Person/Address/Dog/This/That" entity/label as opposed to just a
>> decontextualized bunch of data, Maps and Lists. If Vertex/Edge/Property
>> were to disappear I'd say it would be the first call of duty to write a
>> baby hibernate to bring the property model back in again into userspace.
> Again, the abstraction is still there, but just ALWAYS in a detached form.
>> Regarding jdbc, this kinda makes the point. Sqlg and Hibernate and many
>> many other tools exists precisely so that users do not need to use JDBC
>> with endless hardcoded strings guiding the application. Making TinkerPop
>> more like JDBC is not an obvious plus point.
> So, RemoteConnection differs from JDBC in that its not a fat string, but 
> RemoteConnection.submit(Bytecode). Thus, you still work at the GraphTraversal 
> level in every GLV.
>> A ReferencedElement is also no good as the problem I experience is
>> latency not bandwidth.
> So with ReferenceElements, latency will be less too because it takes less 
> time to construct the ReferenceVertex than it does to construct a 
> DetachedVertex. Imagine a vertex with 100 properties and meta properties. ?!
>> I reckon the experience and usage of TinkerPop is rather different for
>> java and non java people and perhaps even java folks. Hopefully I am not
>> the only one who have made such heavy happy use of the TinkerPop
>> property meta model and would be sad to see it go.
>> Cheers
>> Pieter
>> I agree the focus should be on the Connection (being separate from Graph) 
>> and Traversal. I wouldn't constrain it to "RemoteConnection", just 
>> Connection or GraphConnection. Perhaps there's an EmbeddedConnection and a 
>> RemoteConnection or maybe it's URI-oriented similar to how JDBC does it. In 
>> either case, the behavior  of Remote and Embedded is the same which is what 
>> I think we're striving for.
> Yes. Good point. Just Connection.
>> I would also like to see Transactions be Connection-oriented. With the right 
>> API, it could hook into JTA and be able to take advantage of various 
>> annotations for marking transaction boundaries.
> g = g.openTx()
> g.V().out().out()
> g.addV()
> g.V(1).addE().to(2)
> g.closeTx();
> ??? This way, its all about GraphTraversalSource/GraphTraversal. That is 
> truly the “connection” where the Connection implementation is just 
> provider/machine specific shuffling of Bytecode in and Traversers out.
>> Are there features of a lambda that couldn't be replaced by a more 
>> feature-rich gremlin? 
>> g.V().out('knows').map{it.get().value('name') + ' is the friend name'}
>> g.V().out('knows').map(lambda(concat('name'), ' is the 
>> friend name’))
> So we currently have the concept of g:Lambda and this allows for lambdas to 
> be used remotely.
> g.V().map(function(“it.get().label()”)) // Gremlin-Java traversal with a 
> Gremlin-Groovy lambda.
> The crappy thing is that the lambda is always a String.
>> Reference-only makes total sense. This works really well especially with a 
>> local cache or for use cases where most of the data is stored in a separate 
>> database. I think it would lend itself nicely to lazy loading. When you need 
>> values there are options for that as well (properties/values/valueMap).  One 
>> of the problems with 'attached' elements is you don't know what the 
>> implementation does. So potentially every get or set property call is going 
>> to the database and you don't realize it. That can hurt performance and have 
>> unintended consequences.
> Dude, I’ve been saying this forever. DetachedXXX is a bad idea for the 
> reasons you have stipulated. Just imagine:
> g.V(1).out(‘knows')
> The GraphSON return is every vertex 1 knows and all its properties and meta 
> properties?!?! If you wanted that data too you would have queried for it.
> Marko.

Reply via email to