[
https://issues.apache.org/jira/browse/TINKERPOP-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15212063#comment-15212063
]
Marko A. Rodriguez commented on TINKERPOP-1236:
-----------------------------------------------
I did some playing in the console to demonstrate the compilation.
{code}
gremlin> g.V().as("a").out().as("b").
select("a","b").by("age").by("name")
==>[a:29, b:lop]
==>[a:29, b:vadas]
==>[a:29, b:josh]
==>[a:32, b:ripple]
==>[a:32, b:lop]
==>[a:35, b:lop]
gremlin> g.V().as("a").out().as("b").
select("a").map(values("age")).as("a").
select("b").map(values("name")).as("b").
select(last,"a","b")
==>[a:29, b:lop]
==>[a:29, b:vadas]
==>[a:29, b:josh]
==>[a:32, b:ripple]
==>[a:32, b:lop]
==>[a:35, b:lop]
{code}
Now, watch how these both work in OLAP:
{code}
gremlin> g = TinkerFactory.createModern().traversal().withComputer()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
gremlin> g.V().as("a").out().as("b").
select("a","b").by("age").by("name")
The following path processor step requires more than the element id on
GraphComputer: SelectStep([a, b],[value(age), value(name)]) requires PROPERTIES
Display stack trace? [yN]
gremlin> g.V().as("a").out().as("b").
select("a").map(values("age")).as("a").
select("b").map(values("name")).as("b").
select(last,"a","b")
==>[a:29, b:josh]
==>[a:29, b:vadas]
==>[a:32, b:ripple]
==>[a:35, b:lop]
==>[a:32, b:lop]
==>[a:29, b:lop]
{code}
Until we can mutate paths, this is the problem we introduce:
{code}
gremlin> g.V().as("a").out().as("b").select("a","b").by("age").by("name").path()
==>[v[1], v[3], {a=29, b=lop}]
==>[v[1], v[2], {a=29, b=vadas}]
==>[v[1], v[4], {a=29, b=josh}]
==>[v[4], v[5], {a=32, b=ripple}]
==>[v[4], v[3], {a=32, b=lop}]
==>[v[6], v[3], {a=35, b=lop}]
gremlin>
g.V().as("a").out().as("b").select("a").map(values("age")).as("a").select("b").map(values("name")).as("b").select(last,"a","b").path()
==>[v[1], v[3], v[1], 29, v[3], lop, {a=29, b=lop}]
==>[v[1], v[2], v[1], 29, v[2], vadas, {a=29, b=vadas}]
==>[v[1], v[4], v[1], 29, v[4], josh, {a=29, b=josh}]
==>[v[4], v[5], v[4], 32, v[5], ripple, {a=32, b=ripple}]
==>[v[4], v[3], v[4], 32, v[3], lop, {a=32, b=lop}]
==>[v[6], v[3], v[6], 35, v[3], lop, {a=35, b=lop}]
{code}
The path history of the two expressions is different and thus these are not
"semantically equivalent" traversals.
> SelectDenormalizationStrategy for select().by(starGraph) in OLAP.
> -----------------------------------------------------------------
>
> Key: TINKERPOP-1236
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1236
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.1.1-incubating
> Reporter: Marko A. Rodriguez
>
> Right now, if you do anything beyond {{select().by(id)}} in OLAP, you get a
> {{PathProcessor can't go beyond ElementRequirements.ID}}-style exception.
> This is TOTALLY unacceptable (like totally... I know right.) because
> {{select()}} is so heavily used that it makes the OLAP experience not so
> bueno.
> Enter -- {{SelectDenomalizationStrategy}} which will only be used in OLAP
> compilations.
> {code}
> select("a").by("name") // not allowed in OLAP right now. (1)
> select("a").map(values("name")) // allowed in OLAP. (2)
> {code}
> Thus, compile (1) into (2). However, in a {{while(true)}}-loop until
> {{boolean fullyDenormalized}} you also check on this pattern:
> {code}
> select("a","b").by(outE().count()).by("name") // not allowed in OLAP right
> now (1)
> select("a").by(outE().count()).as("a").select("b").by("name").as("b").select("a","b",Pop.last)
> // not allowed in OLAP right now, but this denormalizes again given the
> first SelectOne pattern
> {code}
> The only problem with this is that future {{select()}} will {{Pop}} a list.
> We need to really make it so we can drop path labels.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
