RemoteGraph

[Stephen Mallette]

Check out this new RemoteGraph business for 3.2.0...

gremlin> graph = RemoteGraph.open('conf/remote-graph.properties')

==>remotegraph[DriverServerConnection-localhost/127.0.0.1:8182 [graph=graph]]

gremlin> g = graph.traversal()

==>graphtraversalsource[remotegraph[DriverServerConnection-localhost/127.0.0.1:8182 [graph=graph]], standard]

gremlin> g.V().valueMap(true)

==>[label:person, name:[marko], id:1, age:[29]]

==>[label:person, name:[vadas], id:2, age:[27]]

==>[label:software, name:[lop], id:3, lang:[java]]

==>[label:person, name:[josh], id:4, age:[32]]

==>[label:software, name:[ripple], id:5, lang:[java]]

==>[label:person, name:[peter], id:6, age:[35]]

So what's happening here? RemoteGraph is a lightweight proxy Graph implementation. Traversals generated from this Graph are automatically serialized and sent to a "remote" - in this case Gremlin Server - where it can be executed and results returned. With this model we say good-bye to doing long strings of gremlin embedded in our code and submitted through the driver and we can just write gremlin directly in the IDE.

Some limitations you will encounter right out of the gate:

* RemoteGraph is not a full Graph implementation. you use it to call graph.traversal() and that's about it

* It does not support lambdas as they are not serializable, but you likely shouldn't be using lambdas anyway in your gremlin so hopefully that's not too big a problem.

We have lots of room for improvement on this work, but this is a good functional beginning. Let the feedback begin.

Enjoy!

Stephen

[Marko Rodriguez]

Hi,

I want to add on to Stephen's notes by saying that providers that want to support remote traversals can do so WITHOUT being required to use GremlinServer. For instance, "advanced providers" like OrientDB and Neo4j, who already have their own full fledge server systems, can support binary traversal submissions by simply implementing RemoteConnection.

http://tinkerpop.apache.org/docs/3.2.0-SNAPSHOT/dev/provider/#remoteconnection-implementations

This idea came from Matthias Bröcheler. His point was that RemoteGraph is a great idea, but forcing vendors to package or support GremlinServer might be too much to ask. With this, Stephen made it so providers can still support RemoteGraph separate from Gremlin Server. In essence, "advanced providers" can be TinkerPop-enabled by:

1. Implementing TinkerPop Graph API.

2. Their server implementing/exposing RemoteConnection.

This asks a lot less of the provider as they can easily add TinkerPop support without having to redefine how their system is deployed for TinkerPop (…that is, they don't need to go into the world of Gremlin Server deployments if they don't want to).  However, for providers that DO NOT have a server model ("not advanced providers" -- bad terminology), they can still be on par with the others because GremlinServer provides all the great server functionality of binary protocol, query routing, metrics, admin tools, and the like. A win-win for all providers regardless of their level of "advancement" (again, bad terminology).

Thanks,

Marko.

http://markorodriguez.com

--
You received this message because you are subscribed to the Google Groups "Gremlin-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/CAA-H43-EXuqdzO7L45xUV4cF%2BLZcmuCjH4-ghtRuLTS-LYkvRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.