[
https://issues.apache.org/jira/browse/TINKERPOP-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-743.
------------------------------
Resolution: Won't Do
Closing given
[discussion|https://lists.apache.org/thread/om2m0phg25s83529p9w0gldmcxz7578h] -
it can be reopened if there is expectation that there will be active work on
this item.
> 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.20.10#820010)
