+1 for {{as('[x]')}}
On Mon, 16 Nov 2015 at 22:48 Marko A. Rodriguez (JIRA) <[email protected]>
wrote:
>
> [
> https://issues.apache.org/jira/browse/TINKERPOP3-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15007287#comment-15007287
> ]
>
> Marko A. Rodriguez commented on TINKERPOP3-743:
> -----------------------------------------------
>
> I still really like this idea.
>
> {code}
> g.V(1).out('friend').as('{x}').out('friend').where(not(within('{x}')))
> {code}
>
> Clean and simple. [~dkuppitz]: do you have any thoughts on the matter?
>
> > Support "barrier syntax" in step labels.
> > ----------------------------------------
> >
> > Key: TINKERPOP3-743
> > URL:
> https://issues.apache.org/jira/browse/TINKERPOP3-743
> > Project: TinkerPop 3
> > Issue Type: Improvement
> > Components: process
> > Affects Versions: 3.0.2-incubating
> > Reporter: Marko A. Rodriguez
> > Assignee: Marko A. Rodriguez
> > Priority: Minor
> >
> > Here is a basic recommendation algorithm that we currently can not do in
> match().
> > {code}
> > g.V(1).as('a').out('likes').aggregate('x'). // what does v[1] like
> > in('likes').where(neq('a')). // who else likes those
> things that are not v[1]
> > out('likes').where(not(within('x')). // what do those people like
> that v[1] doesn't already like
> > groupCount() // count the number of times
> each liked thing is seen
> > {code}
> > Why can't we do this in match()? Because we can not aggregate (well, we
> can, but bare with me). The best we can do is:
> > {code}
> > g.V(1).match('a',
> > as('a').out('likes').as('b'),
> > as('b').in('likes').as('c'),
> > as('c').out('likes').as('d'),
> > where('d',neq('b')),
> > where('a',neq('c'))).
> > select('d').groupCount()
> > {code}
> > So what's the problem? The problem is that where('d',neq('b')) is only
> going to make sure that the current 'd' is not equal to the current 'b'.
> Not the aggregate of all b's. How do we solve this? Here is how we would
> "manually" solve it using Kuppitz' latest idea of adding a clear()-step,
> where clear('x') => sideEffect{it.sideEffects('x').clear()}
> > {code}
> > g.V(1).match('a',
> > as('a').clear('{b}').out('likes').aggregate('{b}').as('b'),
> > as('b').in('likes').as('c'),
> > as('c').out('likes').as('d'),
> > where('d',not(within('{b}'))),
> > where('a',neq('c'))).
> > select('d').groupCount()
> > {code}
> > However, suppose that we make "{ }" (set) and "[ ]" (list) special label
> characters whereby the above is compiled to from the following:
> > {code}
> > g.V(1).match('a',
> > as('a').out('likes').as('{b}'),
> > as('b').in('likes').as('c'),
> > as('c').out('likes').as('d'),
> > where('d',not(within('{b}'))),
> > where('a',neq('c'))).
> > select('d').groupCount()
> > {code}
> > In essence, if an end variable is labeled with "{ }" that means
> aggregate to set ("[ ]" could mean aggregate to list). The variable name
> inside the "{ }" is then the "drain" of the CollectingBarrierStep -- i.e.,
> the single object emission post aggregation. Next, the as("{b}") syntax
> need not be limited to match() where, in fact, the first query of this
> email could be written as:
> > {code}
> > g.V(1).as('a').out('likes').as('{x}').
> > in('likes').where(neq('a')).
> > out('likes').where(not(within('{x}')).
> > groupCount()
> > {code}
> > Where does the clear() go in the above? It goes after the first
> StartStep encountered moving "left." Thus, the previous compiles to the
> following:
> > {code}
> > g.V(1).as('a').clear('{x}').out('likes').aggregate('{x}').as('x')
> > in('likes').where(neq('a')).
> > out('likes').where(not(within('{x}')).
> > groupCount()
> > {code}
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
