[jira] [Assigned] (TINKERPOP-743) Support "barrier syntax" in step labels.

["Stephen Mallette (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TINKERPOP-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stephen Mallette reassigned TINKERPOP-743:
------------------------------------------

    Assignee:     (was: Marko A. Rodriguez)

> Support "barrier syntax" in step labels.
> ----------------------------------------
>
>                 Key: TINKERPOP-743
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-743
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.0.2-incubating
>            Reporter: Marko A. Rodriguez
>            Priority: Minor
>              Labels: breaking
>
> 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
(v8.3.4#803005)