Now all we need is the mid-traversal V/E: https://issues.apache.org/jira/browse/TINKERPOP3-762
Then, the reasoning API will be fully operational. On Tue, Aug 25, 2015 at 6:58 PM, Marko Rodriguez <[email protected]> wrote: > Hi, > > In theory, yes. The problem is that we don't have a g.inject() off > GraphTraversalSource. If you use an anonymous traversal, there is no graph > and thus, AddXXXStep doesn't know the graph to add things too. Thus, we > need something like: > > g.inject('alice', 'bob', 'charlie').as('name'). > addV('person').property('name', select('name')) > > NOTE: In your emails and in your JIRA tickets you tend to word wrap on the > "." and thus, you can't copy/paste your examples into the console. For > instance: > > BAD: > > __('alice', 'bob', 'charlie').as('name') > .addV('person').property('name', select('name')) > > GOOD: > > __('alice', 'bob', 'charlie').as('name'). > addV('person').property('name', select('name')) > > Easy to add… In fact, probably will just add that now. If people have a > better idea than g.inject(…), please advise. > > <coding….> > > Okay. Added to mutating_traverser/ branch (will push once integration > tests complete). Here is your example: > > gremlin> g.inject('alice', 'bob', > 'charlie').as('a').addV('person').property('name', select('a')) > ==>v[0] > ==>v[2] > ==>v[4] > gremlin> g.V().valueMap() > ==>{name=[alice]} > ==>{name=[bob]} > ==>{name=[charlie]} > > Pretty freakin' sweet. > > Thanks, > Marko. > > http://markorodriguez.com > > On Aug 25, 2015, at 5:36 PM, Matt Frantz <[email protected]> > wrote: > > > If you're starting from scratch (empty graph), would you use an anonymous > > traversal to add elements? > > > > __('alice', 'bob', 'charlie').as('name') > > .addV('person').property('name', select('name')) > > > > > > On Tue, Aug 25, 2015 at 3:31 PM, Marko Rodriguez <[email protected]> > > wrote: > > > >> 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 > >>> > >> > >> > >
