Hello,
The mutating_traverser/ branch has the implementation of the proposal
discussed in the previous email.
https://github.com/apache/incubator-tinkerpop/tree/mutating_traverser
Here is the key change to the GraphTraversal DSL:
https://github.com/apache/incubator-tinkerpop/blob/mutating_traverser/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java#L640-L726
Here is a Gremlin Console session so people can see how nice the new model is:
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().as('a').out('created').addE('createdBy').to('a')
==>e[12][3-createdBy->1]
==>e[13][5-createdBy->4]
==>e[14][3-createdBy->4]
==>e[15][3-createdBy->6]
gremlin> g.V().as('a').outE('created').as('b').inV().
addE('createdBy').to('a').property('weight',select('b').values('weight')).
valueMap()
==>[weight:0.4]
==>[weight:1.0]
==>[weight:0.4]
==>[weight:0.2]
gremlin> g.V().as('a').addE('pet').to(addV('animal').property('name',
select('a').by('name').map{it.get() + "'s pet"}))
==>e[26][1-pet->24]
==>e[29][2-pet->27]
==>e[32][3-pet->30]
==>e[35][4-pet->33]
==>e[38][5-pet->36]
==>e[41][6-pet->39]
gremlin> g.V().hasLabel('animal').valueMap()
==>[name:[josh's pet]]
==>[name:[ripple's pet]]
==>[name:[peter's pet]]
==>[name:[marko's pet]]
==>[name:[vadas's pet]]
==>[name:[lop's pet]]
Pretty wicked, eh?
Note that that the old Mutation methods still exist (though they are
@Deprecated) and they simply call those new AddXXXStep steps accordingly. The
only thing left to do is update the documentation.
Please review the work and if you are happy, I can merge master/ and then
update the docs.
Thanks,
Marko.
http://markorodriguez.com
On Aug 25, 2015, at 9:44 AM, Marko Rodriguez <[email protected]> wrote:
> Hello,
>
> TinkerPop3 made a stance against TinkerPop2 and said: "there are no such
> thing as lambdas --- lambdas are traversals!"
>
> Next --- the mutation steps in TinkerPop3 are sorta clunky and ugly.
> Moreover, people want mid-traversal parameterization. That is, something like:
>
> addV(T.label, select("a").label())
>
> This got us to thinking. EVERYTHING IS A TRAVERSAL. There are no such things
> a primitives. Gremlin works with only one type of object -- Traversal. While
> this sounds crazy, its actual realization into TinkerPop 3.1.0 would be
> simple. However, our mutation steps as we have them now, would be
> @Deprecated. :( Everything else would stay the same. :) Ignoring the general
> theory of "EVERYTHING IS A TRAVERSAL," lets look at a practical day one
> ramification.
>
> Here is the thread of thought:
> https://issues.apache.org/jira/browse/TINKERPOP3-799
>
> Here is a break down of what of what we propose for TinkerPop 3.1.0.
>
> addV("person").property("name","marko")
> addV("person").property("name",select("a").by("name"))
> addE("likes").from("a").to("b")
> addE("knows").from(select("a").in("likes")).to(select("b").in("employees"))
> addE("likes").from(select("a").in("likes")).to("a")
> addE("likes").from("a").to("b").property(select("a").by("key"),select("a").by("value"))
> out(select("a").label())
>
> In short, every step's parameters can be traversals which are evaluated at
> runtime. Thus, the query is parameterized by the traverser. Psychedelic.
>
> For now, I'm not so interested in out(select("a").label()) as much as in
> cleaning up the mutation steps (property(), addV(), addE()) as this is where
> people seem to want this type of runtime parameterization and where our
> current GraphTraversal API is weak.
>
> If anyone has any thoughts on the matter, please espouse them.
>
> *** Note for vendors. I know Titan, so I will show how this is crazy for
> Titan and hopefully other vendors see the complexity. When a user does
> out(select("a").label()), then Titan's vertex-centric index step will NOT
> have the edge label at compile-time, but will have to compute for each and
> every traverser. I have already created a very nice object called
> "Parameters" which makes this easy, but still…….. This is also why I just
> want to focus on the mutation steps for now as those are not vendor optimized
> (as far as I know) and it provides us the most bang for our buck.
>
> Thanks,
> Marko.
>
> http://markorodriguez.com
>
