[jira] [Commented] (TINKERPOP-1380) dedup() doesn't dedup in rare cases

[Marko A. Rodriguez (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830245#comment-15830245
 ] 

Marko A. Rodriguez commented on TINKERPOP-1380:
---

Your examples seem to work now:

{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> 
g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup().dedup()
==>v[1]
==>v[3]
==>v[4]
==>v[2]
==>v[5]
==>v[6]
gremlin>  
g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup()
==>v[1]
==>v[3]
==>v[4]
==>v[2]
==>v[5]
==>v[6]
gremlin> 
g.withComputer().V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup().dedup()
==>v[1]
==>v[2]
==>v[3]
==>v[4]
==>v[5]
==>v[6]
gremlin> 
g.withComputer().V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup().dedup()
==>v[1]
==>v[2]
==>v[3]
==>v[4]
==>v[5]
==>v[6]
{code}

(this is in tp32/).

[~dkuppitz] Perhaps you can add your examples to the test suite and if they 
pass, great. CTR and close this ticket.

> 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.4
>
>
> 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)

[jira] [Commented] (TINKERPOP-1380) dedup() doesn't dedup in rare cases

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387523#comment-15387523
 ] 

stephen mallette commented on TINKERPOP-1380:
-

I'm good with breaking this up into multiple tickets.

> Maybe clone() should throw an exception if the traversal was already iterated.

I'm not so sure it should behave that way. cloning the traversal is the only 
way to re-execute it (that i know of) after it has been iterated. i have this 
feeling there are reasons clone copies sideeffects. it might have had to do 
with what we were doing with {{Traversal}} serialization prior to the approach 
we now have with {{Bytecode}}. Anyway - a separate issue to deal with that 
sounds good to me.

> 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)

[jira] [Commented] (TINKERPOP-1380) dedup() doesn't dedup in rare cases

[Daniel Kuppitz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387444#comment-15387444
 ] 

Daniel Kuppitz commented on TINKERPOP-1380:
---

A simple test case we could add is this one:

{code}
gremlin> 
TinkerFactory.createModern().traversal().withComputer().V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x")
==>{v[1]=21, v[2]=1, v[3]=21, v[4]=21, v[6]=1, v[5]=1}
==>{v[1]=21, v[2]=1, v[3]=21, v[4]=21, v[6]=1, v[5]=1}
{code}

The test should verify that the result size is 1.

> 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)

[jira] [Commented] (TINKERPOP-1380) dedup() doesn't dedup in rare cases

[Daniel Kuppitz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387407#comment-15387407
 ] 

Daniel Kuppitz commented on TINKERPOP-1380:
---

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)

[jira] [Commented] (TINKERPOP-1380) dedup() doesn't dedup in rare cases

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15386472#comment-15386472
 ] 

stephen mallette commented on TINKERPOP-1380:
-

I just noticed this which [~dkuppitz] thinks might be related to this issue:

{code}
gremlin> t = g.V().aggregate('a')
==>v[1]
==>v[2]
==>v[3]
==>v[4]
==>v[5]
==>v[6]
gremlin> t.clone()
==>v[1]
==>v[2]
==>v[3]
==>v[4]
==>v[5]
==>v[6]
gremlin> t.getSideEffects().get('a')
==>v[1]
==>v[1]
==>v[2]
==>v[2]
==>v[3]
==>v[3]
==>v[4]
==>v[4]
==>v[5]
==>v[5]
==>v[6]
==>v[6]
{code}

calls to {{clone()}} are keeping side-effects. perhaps that is the root of the 
problem here?

> 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
>
> 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)