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
On Mar 18, 2016, at 7:32 AM, Stephen Mallette <spmalle...@gmail.com> wrote:
> 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
>
>
>
>
>
>
> --
> 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-users+unsubscr...@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.
