[
https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387407#comment-15387407
]
Daniel Kuppitz edited comment on TINKERPOP-1380 at 7/21/16 9:08 AM:
--------------------------------------------------------------------
I inspected the side-effects in my original traversal and they actually look
good. But what I found is that {{cap("p")}} emits 2 results.
{code}
gremlin>
g.withComputer().V().emit(cyclicPath().or().not(both())).repeat(both()).until(cyclicPath()).
gremlin> aggregate("p").by(path()).cap("p")
==>{[v[0]]=1, [v[1], v[2], v[1]]=1, [v[2], v[1], v[2]]=1}
==>{[v[0]]=1, [v[1], v[2], v[1]]=1, [v[2], v[1], v[2]]=1}
{code}
By explicitly limiting it to 1 result, {{dedup()}} gives the expected result:
{code}
gremlin>
g.withComputer().V().emit(cyclicPath().or().not(both())).repeat(both()).until(cyclicPath()).
gremlin> aggregate("p").by(path()).cap("p").limit(1).unfold().limit(local,
1).map(
gremlin> __.as("v").select("p").unfold().
gremlin> filter(unfold().where(eq("v"))).
gremlin> unfold().dedup().order().by(id).fold()
gremlin> ).dedup()
==>[v[1], v[2]]
==>[v[0]]
{code}
So it looks like it's more of a {{cap()}} problem. Perhaps we should change the
title of this ticket and also split it into 3 separate tickets.
We have:
* {{dedup()}} sometimes doesn't dedup
* some usages if {{dedup()}} lead to exceptions
* {{cap}} in OLAP emits 2 results instead of just 1
* side-effects get duplicated
I thought about the last one a bit longer and I think it's not a bug. The
"problem" is, that the original traversal was already executed; the result is
confusing, but actually what should be expected. Maybe {{clone()}} should throw
an exception if the traversal was already iterated.
was (Author: dkuppitz):
I inspected the side-effects in my original traversal and the actually look
good. But what I found is that {{cap("p")}} emits 2 results.
{code}
gremlin>
g.withComputer().V().emit(cyclicPath().or().not(both())).repeat(both()).until(cyclicPath()).
gremlin> aggregate("p").by(path()).cap("p")
==>{[v[0]]=1, [v[1], v[2], v[1]]=1, [v[2], v[1], v[2]]=1}
==>{[v[0]]=1, [v[1], v[2], v[1]]=1, [v[2], v[1], v[2]]=1}
{code}
By explicitly limiting it to 1 result, {{dedup()}} gives the expected result:
{code}
gremlin>
g.withComputer().V().emit(cyclicPath().or().not(both())).repeat(both()).until(cyclicPath()).
gremlin> aggregate("p").by(path()).cap("p").limit(1).unfold().limit(local,
1).map(
gremlin> __.as("v").select("p").unfold().
gremlin> filter(unfold().where(eq("v"))).
gremlin> unfold().dedup().order().by(id).fold()
gremlin> ).dedup()
==>[v[1], v[2]]
==>[v[0]]
{code}
So it looks like it's more of a {{cap()}} problem. Perhaps we should change the
title of this ticket and also split it into 3 separate tickets.
We have:
* {{dedup()}} sometimes doesn't dedup
* some usages if {{dedup()}} lead to exceptions
* {{cap}} in OLAP emits 2 results instead of just 1
* side-effects get duplicated
I thought about the last one a bit longer and I think it's not a bug. The
"problem" is, that the original traversal was already executed; the result is
confusing, but actually what should be expected. Maybe {{clone()}} should throw
an exception if the traversal was already iterated.
> dedup() doesn't dedup in rare cases
> -----------------------------------
>
> Key: TINKERPOP-1380
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1380
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.2.1
> Reporter: Daniel Kuppitz
> Fix For: 3.2.2
>
>
> I stumbled across this issue when I tried to solve a problem on the mailing
> list. It seems like a lot of steps need to be involved in order to make it
> reproducible.
> {code}
> gremlin> :set max-iteration 10
> gremlin>
> gremlin> g = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin>
> g.V().repeat(both()).until(cyclicPath()).path().aggregate("x").cap("x").unfold().dedup()
> ==>[v[1], v[2], v[1]]
> ==>[v[1], v[2], v[1]]
> ==>[v[1], v[3], v[1]]
> ==>[v[1], v[3], v[1]]
> ==>[v[1], v[4], v[1]]
> ==>[v[1], v[4], v[1]]
> ==>[v[2], v[1], v[2]]
> ==>[v[2], v[1], v[2]]
> ==>[v[3], v[1], v[3]]
> ==>[v[3], v[1], v[3]]
> ...
> {code}
> I can't reproduce it w/o using {{repeat()}}, {{aggregate()}} or {{cap()}}. It
> is reproducible without {{path()}} though. And then it even gets a little
> worse; check this out:
> {code}
> gremlin>
> g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup()
> ==>v[1]
> ==>v[1]
> ==>v[2]
> ==>v[2]
> ==>v[3]
> ==>v[3]
> ==>v[4]
> ==>v[4]
> ==>v[5]
> ==>v[5]
> ...
> gremlin>
> g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup().dedup()
> java.lang.RuntimeException: java.lang.IllegalStateException:
> java.lang.IllegalArgumentException: The memory can only be set() during
> vertex program setup and terminate: x
> Display stack trace? [yN]
> {code}
> The exception occurs only in OLAP mode, but also for more meaningful patterns
> ({{.dedup().dedup()}} really doesn't make much sense).
> For a better / larger example see:
> https://groups.google.com/d/msg/gremlin-users/NMXExuvDjt0/ps7bJDYwAQAJ
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
