Sorry, someone took out dev@ in the original email of my reply below. Marko.
http://markorodriguez.com > Begin forwarded message: > > From: Marko Rodriguez <okramma...@gmail.com> > Subject: Re: [TinkerPop] gremlin-x > Date: December 1, 2016 at 11:38:21 AM MST > To: gremlin-us...@googlegroups.com > > Hi, > > PIETER REPLIES: > >> 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() > v.id > > 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 >> > > > ROBERT REPLIES: > >> 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(__.it.get().value('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.
