[jira] [Closed] (TINKERPOP-1084) Branch option tokens should be allowed to be traversals.
[
https://issues.apache.org/jira/browse/TINKERPOP-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1084.
-
Resolution: Fixed
Fix Version/s: 3.5.0
3.4.3
3.3.8
> Branch option tokens should be allowed to be traversals.
>
>
> Key: TINKERPOP-1084
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1084
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.8, 3.4.3, 3.5.0
>
>
> It would be cool if we could do this:
> {code}
> g.V().hasLabel("person").
> choose(values("age")).
> option(is(lt(28)), constant("low")).
> option(is(between(29,30)), constant("medium"))
> option(none,constant("high"))
> {code}
> That is, "option tokens" can be traversals and if they are evaluate the
> traversal as a predicate.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (TINKERPOP-2230) match() step unexpected behaviours
[
https://issues.apache.org/jira/browse/TINKERPOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz resolved TINKERPOP-2230.
---
Resolution: Fixed
Fix Version/s: 3.5.0
3.4.3
3.3.8
> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
> Labels: gremlin
> Fix For: 3.3.8, 3.4.3, 3.5.0
>
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a),
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b),
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually
> contains a solvable form of patterns. It's really confusing; if you want,
> create a Jira ticket for that issue, perhaps someone dares to analyze that
> crazy code"
> please see
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
> for more information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (TINKERPOP-1084) Branch option tokens should be allowed to be traversals.
[
https://issues.apache.org/jira/browse/TINKERPOP-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TINKERPOP-1084 started by Daniel Kuppitz.
-
> Branch option tokens should be allowed to be traversals.
>
>
> Key: TINKERPOP-1084
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1084
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>Priority: Major
>
> It would be cool if we could do this:
> {code}
> g.V().hasLabel("person").
> choose(values("age")).
> option(is(lt(28)), constant("low")).
> option(is(between(29,30)), constant("medium"))
> option(none,constant("high"))
> {code}
> That is, "option tokens" can be traversals and if they are evaluate the
> traversal as a predicate.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (TINKERPOP-1084) Branch option tokens should be allowed to be traversals.
[
https://issues.apache.org/jira/browse/TINKERPOP-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz reassigned TINKERPOP-1084:
-
Assignee: Daniel Kuppitz
> Branch option tokens should be allowed to be traversals.
>
>
> Key: TINKERPOP-1084
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1084
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>Priority: Major
>
> It would be cool if we could do this:
> {code}
> g.V().hasLabel("person").
> choose(values("age")).
> option(is(lt(28)), constant("low")).
> option(is(between(29,30)), constant("medium"))
> option(none,constant("high"))
> {code}
> That is, "option tokens" can be traversals and if they are evaluate the
> traversal as a predicate.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2230) match() step unexpected behaviours
[
https://issues.apache.org/jira/browse/TINKERPOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853090#comment-16853090
]
Daniel Kuppitz commented on TINKERPOP-2230:
---
It will most likely be part of 3.3.8 and 3.4.3.
> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
> Labels: gremlin
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a),
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b),
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually
> contains a solvable form of patterns. It's really confusing; if you want,
> create a Jira ticket for that issue, perhaps someone dares to analyze that
> crazy code"
> please see
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
> for more information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2230) match() step unexpected behaviours
[
https://issues.apache.org/jira/browse/TINKERPOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852270#comment-16852270
]
Daniel Kuppitz commented on TINKERPOP-2230:
---
To me it looked like the implementation made the assumption that patterns are
always circular (e.g. you can pick a random start label and from there you can
reach any other label). Also, the user-defined start step (the start step of
your first pattern) was never moved, so if you came up with pre-sorted solvable
sequence, you wouldn't have run into an error.
Now, bad things started to happen if there's a start label that is never used
as an end label. The start step discovery algorithm didn't force this child
pattern to be pushed to the top (and thus define the ultimate start label).
Hence, you sometimes got the unsolvable pattern error, although all child
patterns as a whole would have produced a valid pattern (if only the start step
would have been be right).
> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
> Labels: gremlin
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a),
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b),
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually
> contains a solvable form of patterns. It's really confusing; if you want,
> create a Jira ticket for that issue, perhaps someone dares to analyze that
> crazy code"
> please see
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
> for more information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2230) match() step unexpected behaviours
[
https://issues.apache.org/jira/browse/TINKERPOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849990#comment-16849990
]
Daniel Kuppitz commented on TINKERPOP-2230:
---
I think I solved it. It seems that the internal sorting is not causing any
issues, but the determination of the start step can screw things up. Running
the full integration test suite right now. If everything passes, I'll pus the
PR out as soon as the branches are open for development again.
> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
> Labels: gremlin
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a),
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b),
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually
> contains a solvable form of patterns. It's really confusing; if you want,
> create a Jira ticket for that issue, perhaps someone dares to analyze that
> crazy code"
> please see
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
> for more information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (TINKERPOP-2230) match() step unexpected behaviours
[
https://issues.apache.org/jira/browse/TINKERPOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz reassigned TINKERPOP-2230:
-
Assignee: Daniel Kuppitz
> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
> Labels: gremlin
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a),
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b),
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually
> contains a solvable form of patterns. It's really confusing; if you want,
> create a Jira ticket for that issue, perhaps someone dares to analyze that
> crazy code"
> please see
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
> for more information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results
[
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844368#comment-16844368
]
Daniel Kuppitz commented on TINKERPOP-2220:
---
{quote}we'd be processing *v[6]* twice at _depth=3_, only to later dedup the
duplicate pairs created from the double traversal{quote}
You are saying that you want to deduplicate the pair, but in your query, you
deduplicate the vertex.
{code}
// what you want
g.V(1).repeat(identity().as("incoming").project("d","v").by(loops()).by(identity()).dedup().aggregate("pairs").select("incoming").out()).cap("pairs")
// what you bring up as a non-working example
g.V(1).repeat(identity().as("incoming").project("d","v").by(loops()).by(identity()).aggregate("pairs").select("incoming").out().dedup()).cap("pairs")
{code}
> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0
> results, while dedup twice produced the correct 6.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results
[
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16842565#comment-16842565
]
Daniel Kuppitz commented on TINKERPOP-2220:
---
Just had another idea on how to explain it. Instead of {{dedup()}} let's just
use a filter lambda that follows the same rules (and prints some debug
messages):
{code}
gremlin> dedupLambda = {
..1> element = it.get()
..2> step = it.getStepId()
..3> if ((m = (step =~ /[0-9]+\.[0-9]+\.[0-9]+\(\)/)).find()) {
..4> step = m.group()
..5> }
..6> seen = memory[step]?.contains(element)
..7> memory[step] = (memory[step] ?: []) + [element]
..8> println "${element} seen at step ${step}: ${seen ? 'yes (filter it)'
: 'no (let it pass)'}"
..9> return !seen
.10> }
==>groovysh_evaluate$_run_closure1@67514bdd
gremlin>
gremlin> memory = [:] ; g.V().filter(dedupLambda).filter(dedupLambda).count()
v[1] seen at step 1.0.0(): no (let it pass)
v[1] seen at step 2.0.0(): no (let it pass)
v[2] seen at step 1.0.0(): no (let it pass)
v[2] seen at step 2.0.0(): no (let it pass)
v[3] seen at step 1.0.0(): no (let it pass)
v[3] seen at step 2.0.0(): no (let it pass)
v[4] seen at step 1.0.0(): no (let it pass)
v[4] seen at step 2.0.0(): no (let it pass)
v[5] seen at step 1.0.0(): no (let it pass)
v[5] seen at step 2.0.0(): no (let it pass)
v[6] seen at step 1.0.0(): no (let it pass)
v[6] seen at step 2.0.0(): no (let it pass)
==>6
gremlin> memory = [:] ; g.V().repeat(filter(dedupLambda)).times(2).count()
v[1] seen at step 1.0.0(): no (let it pass)
v[1] seen at step 1.0.0(): yes (filter it)
v[2] seen at step 1.0.0(): no (let it pass)
v[2] seen at step 1.0.0(): yes (filter it)
v[3] seen at step 1.0.0(): no (let it pass)
v[3] seen at step 1.0.0(): yes (filter it)
v[4] seen at step 1.0.0(): no (let it pass)
v[4] seen at step 1.0.0(): yes (filter it)
v[5] seen at step 1.0.0(): no (let it pass)
v[5] seen at step 1.0.0(): yes (filter it)
v[6] seen at step 1.0.0(): no (let it pass)
v[6] seen at step 1.0.0(): yes (filter it)
==>0
{code}
> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0
> results, while dedup twice produced the correct 6.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results
[
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16842470#comment-16842470
]
Daniel Kuppitz commented on TINKERPOP-2220:
---
{{dedup()}} is a {{FilterStep}}. Think about it, {{repeat(whatever).times(2)}}
is supposed to emit whatever is left after the 2nd iteration. For
{{repeat(dedup()).times(2)}} there's just nothing left in the stream as every
element gets filtered in the 2nd iteration.
{code}
gremlin> g.V().repeat(dedup()).times(2).count()
==>0
gremlin> g.V().repeat(dedup()).emit().times(2).count()
==>6
{code}
If you emit all elements after each iteration, you'll get all the survivors
from iteration 1. Does it make any more sense now?
It's not the same as {{dedup().dedup()}} as this only ensures uniqueness at two
different steps in the traversal. And because it's not the same,
{{RepeatUnrollStrategy}} won't do anything if it finds a {{DedupStep}}.
> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0
> results, while dedup twice produced the correct 6.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results
[
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2220.
-
Resolution: Not A Bug
> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0
> results, while dedup twice produced the correct 6.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results
[
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16842317#comment-16842317
]
Daniel Kuppitz edited comment on TINKERPOP-2220 at 5/17/19 5:10 PM:
The meaning of {{dedup()}} inside {{repeat()}} is a little different. Just like
{{simplePath}} ensures that no element appears twice on the current path,
{{repeat(dedup())}} ensures that no element is visited twice within the
repetition.
{code}
gremlin> g.V(1).repeat(both().simplePath()).emit().path()
==>[v[1],v[3]]
==>[v[1],v[2]]
==>[v[1],v[4]]
==>[v[1],v[3],v[4]]
==>[v[1],v[3],v[6]]
==>[v[1],v[4],v[5]]
==>[v[1],v[4],v[3]]
==>[v[1],v[3],v[4],v[5]]
==>[v[1],v[4],v[3],v[6]]
{code}
Note, how the two longest paths visit {{v[5]}} and {{v[6]}} in the end
(although these 2 vertices were already seen in shorter paths. Now watch this:
{code}
gremlin> g.V(1).repeat(both().simplePath().dedup()).emit().path()
==>[v[1],v[3]]
==>[v[1],v[2]]
==>[v[1],v[4]]
==>[v[1],v[3],v[6]]
==>[v[1],v[4],v[5]]
{code}
{{dedup()}} inside {{repeat()}} makes sure that this doesn't happen. In other
cases, you don't really need to worry about deduplication; if two traversers
hit the same element, they will merge. Thus, from a performance and memory
perspective, it makes no difference if an element appears once or a thousand
times within {{repeat()}}.
was (Author: dkuppitz):
The meaning of {{dedup()}} inside {{repeat()}} is a little different. Just like
{{simplePath}} ensures that no element appears twice on the current path,
{{repeat(dedup())}} ensures that no element is visited twice within the
repetition.
> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0
> results, while dedup twice produced the correct 6.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results
[
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16842317#comment-16842317
]
Daniel Kuppitz commented on TINKERPOP-2220:
---
The meaning of {{dedup()}} inside {{repeat()}} is a little different. Just like
{{simplePath}} ensures that no element appears twice on the current path,
{{repeat(dedup())}} ensures that no element is visited twice within the
repetition.
> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0
> results, while dedup twice produced the correct 6.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed
[
https://issues.apache.org/jira/browse/TINKERPOP-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834193#comment-16834193
]
Daniel Kuppitz commented on TINKERPOP-2209:
---
This is a known issue: https://issues.apache.org/jira/browse/TINKERPOP-1048
Unfortunately, I don't think we can change that. TinkerPop itself ignores
numeric data types (meaning, an Integer 1 is considered equal to a Long 1). But
when it comes to the graph step, it's really up to the provider, e.g. how he
decides to translate the provided input variables to a backend query.
I'm not entirely sure about it, but my guess is, that there are 2 different
code paths in {{JanusGraphStep}} / {{JanusGraphStepStrategy}} - one of them
converts the Integers, the other doesn't.
> hasId is not converting properly when multiple values are passed
>
>
> Key: TINKERPOP-2209
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2209
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.3
> Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook.
>Reporter: Chris Hupman
>Priority: Minor
>
> While [trying to answer a question on Stack Overflow
> |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]]
> I found that hasId is performing `~id.eq` against arrays instead of
> `~id.within` For a workaround the user reporting the issue found that quoting
> the values or converting them to longs worked.
>
> ```
> {{ids = [8440,12536]}}
> {{paths =
> g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}}
> {{paths =
> g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}}
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed
[
https://issues.apache.org/jira/browse/TINKERPOP-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834103#comment-16834103
]
Daniel Kuppitz commented on TINKERPOP-2209:
---
This is the expected behavior. {{hasId}} accepts varargs; a collection is a
single argument, thus it will be translated into {{eq()}}. However, if you pass
an array, it will be translated into {{within}}.
{code:java}
gremlin> ids = [8440,12536]
==>8440
==>12536
gremlin>
g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().toString()[0..<100]
==>[GraphStep(vertex,[8440, 12536]), RepeatStep(until([HasStep([~id.eq([8440,
12536])])]),[VertexStep(O
gremlin> ids = [8440,12536].toArray()
==>8440
==>12536
gremlin>
g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().toString()[0..<100]
==>[GraphStep(vertex,[8440, 12536]),
RepeatStep(until([HasStep([~id.within([8440, 12536])])]),[VertexSt
{code}
{{g.V(ids)}} returns all vertices, because {{GraphStep}} is the only step that
unfolds collections internally. {{g.V().hasId(ids)}} returns all vertices,
because in this case, {{hasId}} gets folded into {{GraphStep}}. Theoretically,
we could remove the automatic unfolding in {{GraphStep}}, but practically, this
would be a major breaking change. Likewise, we can't do the automatic unfolding
for every other step, as you wouldn't be able to actually test for equal
collections anymore.
> hasId is not converting properly when multiple values are passed
>
>
> Key: TINKERPOP-2209
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2209
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.3
> Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook.
>Reporter: Chris Hupman
>Priority: Minor
>
> While [trying to answer a question on Stack Overflow
> |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]]
> I found that hasId is performing `~id.eq` against arrays instead of
> `~id.within` For a workaround the user reporting the issue found that quoting
> the values or converting them to longs worked.
>
> ```
> {{ids = [8440,12536]}}
> {{paths =
> g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}}
> {{paths =
> g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}}
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2187) Two issues with the ShortestPathVertexProgram
[
https://issues.apache.org/jira/browse/TINKERPOP-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832806#comment-16832806
]
Daniel Kuppitz commented on TINKERPOP-2187:
---
Also, see the JavaDoc for {{MessageCombiner}}:
{quote}
* A MessageCombiner allows two messages in route to the same vertex to be
aggregated into a single message.
* Message combining can reduce the number of messages sent between vertices
and thus, reduce network traffic.
* Not all messages can be combined and thus, this is an optional feature of a
VertexProgram.
{quote}
In other words, a {{GraphComputer}} should work in any case, whether the
message combiner is provided or not.
> Two issues with the ShortestPathVertexProgram
> -
>
> Key: TINKERPOP-2187
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2187
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.1
>Reporter: Florian Hockmann
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> While trying to update JanusGraph to TinkerPop 3.4.0, I encountered two
> issues with the {{ShortestPathVertexProgramm}}:
> # {{ShortestPathVertexProgram.getMessageScopes()}} returns an empty
> collection which doesn't work for a graph computer that uses these scopes to
> execute the edge traversal. I think the scopes should be {{Global}} and
> {{Local}} with the edge traversal.
> # The {{ShortestPathVertexProgram}} defines no message combiner, but
> {{sendMessages()}} can apparently still send multiple messages for the same
> vertex.
> For some reason, this doesn't lead to any problems for the
> {{TinkerGraphComputer}}. (Maybe it receives each message before another one
> can be sent for the same vertex?)
> For {{FulgoraGraphComputer}} however some tests result in a situation where
> multiple messages are sent to the same vertex which fails because no combiner
> is defined.
> So, I'd say that the {{ShortestPathVertexProgram}} should have a message
> combiner.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2187) Two issues with the ShortestPathVertexProgram
[
https://issues.apache.org/jira/browse/TINKERPOP-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832805#comment-16832805
]
Daniel Kuppitz commented on TINKERPOP-2187:
---
The message scope should be {{Global}} only, SPVP never sends local messages.
Logically, a message combiner doesn't make much sense IMO. There's nothing to
combine to reduce the message size, all I could do is turn messages into Lists
of Triplets. However, that means messages would become larger (perhaps too
large in certain scenarios). I'm wondering if there's something wrong in
FulgoraGraphComputer; it really should just process every incoming message.
> Two issues with the ShortestPathVertexProgram
> -
>
> Key: TINKERPOP-2187
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2187
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.1
>Reporter: Florian Hockmann
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> While trying to update JanusGraph to TinkerPop 3.4.0, I encountered two
> issues with the {{ShortestPathVertexProgramm}}:
> # {{ShortestPathVertexProgram.getMessageScopes()}} returns an empty
> collection which doesn't work for a graph computer that uses these scopes to
> execute the edge traversal. I think the scopes should be {{Global}} and
> {{Local}} with the edge traversal.
> # The {{ShortestPathVertexProgram}} defines no message combiner, but
> {{sendMessages()}} can apparently still send multiple messages for the same
> vertex.
> For some reason, this doesn't lead to any problems for the
> {{TinkerGraphComputer}}. (Maybe it receives each message before another one
> can be sent for the same vertex?)
> For {{FulgoraGraphComputer}} however some tests result in a situation where
> multiple messages are sent to the same vertex which fails because no combiner
> is defined.
> So, I'd say that the {{ShortestPathVertexProgram}} should have a message
> combiner.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (TINKERPOP-2187) Two issues with the ShortestPathVertexProgram
[
https://issues.apache.org/jira/browse/TINKERPOP-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz reassigned TINKERPOP-2187:
-
Assignee: Daniel Kuppitz
> Two issues with the ShortestPathVertexProgram
> -
>
> Key: TINKERPOP-2187
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2187
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.1
>Reporter: Florian Hockmann
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> While trying to update JanusGraph to TinkerPop 3.4.0, I encountered two
> issues with the {{ShortestPathVertexProgramm}}:
> # {{ShortestPathVertexProgram.getMessageScopes()}} returns an empty
> collection which doesn't work for a graph computer that uses these scopes to
> execute the edge traversal. I think the scopes should be {{Global}} and
> {{Local}} with the edge traversal.
> # The {{ShortestPathVertexProgram}} defines no message combiner, but
> {{sendMessages()}} can apparently still send multiple messages for the same
> vertex.
> For some reason, this doesn't lead to any problems for the
> {{TinkerGraphComputer}}. (Maybe it receives each message before another one
> can be sent for the same vertex?)
> For {{FulgoraGraphComputer}} however some tests result in a situation where
> multiple messages are sent to the same vertex which fails because no combiner
> is defined.
> So, I'd say that the {{ShortestPathVertexProgram}} should have a message
> combiner.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2207) Provide SimpleValueMapStrategy
Daniel Kuppitz created TINKERPOP-2207:
-
Summary: Provide SimpleValueMapStrategy
Key: TINKERPOP-2207
URL: https://issues.apache.org/jira/browse/TINKERPOP-2207
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.4.1
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
Implement a {{SimpleValueMapStrategy}} that can be used by providers who do not
support multi-valued properties. The strategy should automatically unfold
{{valueMap()}}'s values and thus turn them into single values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2191) Implement EdgeLabelVerificationStrategy
[ https://issues.apache.org/jira/browse/TINKERPOP-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz closed TINKERPOP-2191. - Resolution: Fixed Fix Version/s: 3.4.2 3.3.7 > Implement EdgeLabelVerificationStrategy > --- > > Key: TINKERPOP-2191 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2191 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.3.6, 3.4.1 >Reporter: Daniel Kuppitz >Assignee: Daniel Kuppitz >Priority: Major > Fix For: 3.3.7, 3.4.2 > > > Using edge-steps, without specifying any labels, is documented as an > anti-pattern. We should have a strategy that verifies that all edge-steps > specify at least one label. > The strategy should not be added by default, as not every provider may agree > that this an anti-pattern. It should also be possible to choose how the > strategy behaves, e.g. whether it throws an exception or only logs a warning > message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2191) Implement EdgeLabelVerificationStrategy
[ https://issues.apache.org/jira/browse/TINKERPOP-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz updated TINKERPOP-2191: -- Summary: Implement EdgeLabelVerificationStrategy (was: Implement LabelVerificationStrategy) > Implement EdgeLabelVerificationStrategy > --- > > Key: TINKERPOP-2191 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2191 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.3.6, 3.4.1 >Reporter: Daniel Kuppitz >Assignee: Daniel Kuppitz >Priority: Major > > Using edge-steps, without specifying any labels, is documented as an > anti-pattern. We should have a strategy that verifies that all edge-steps > specify at least one label. > The strategy should not be added by default, as not every provider may agree > that this an anti-pattern. It should also be possible to choose how the > strategy behaves, e.g. whether it throws an exception or only logs a warning > message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2191) Implement LabelVerificationStrategy
Daniel Kuppitz created TINKERPOP-2191: - Summary: Implement LabelVerificationStrategy Key: TINKERPOP-2191 URL: https://issues.apache.org/jira/browse/TINKERPOP-2191 Project: TinkerPop Issue Type: Improvement Components: process Affects Versions: 3.4.1, 3.3.6 Reporter: Daniel Kuppitz Assignee: Daniel Kuppitz Using edge-steps, without specifying any labels, is documented as an anti-pattern. We should have a strategy that verifies that all edge-steps specify at least one label. The strategy should not be added by default, as not every provider may agree that this an anti-pattern. It should also be possible to choose how the strategy behaves, e.g. whether it throws an exception or only logs a warning message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2170) Compare.eq doesn't produce consistent results
[
https://issues.apache.org/jira/browse/TINKERPOP-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778010#comment-16778010
]
Daniel Kuppitz commented on TINKERPOP-2170:
---
Are you saying that this worked before? We were aware of the rounding issues,
but that's a limitation dictated by the JVM.
{noformat}
gremlin> 1f==1d
==>true
gremlin> 1.53f==1.53d
==>false
{noformat}
> Compare.eq doesn't produce consistent results
> -
>
> Key: TINKERPOP-2170
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2170
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.4
>Reporter: Daniel Choi
>Assignee: Daniel Kuppitz
>Priority: Major
>
> https://issues.apache.org/jira/browse/TINKERPOP-2056 introduced a change to
> start using NumberHelper for comparisons.
>
> This seems to have introduced an interesting side effect:
> {code:java}
> Assert.assertTrue(Compare.eq.test(new Double(1.53), new Float(1.53)));
> {code}
> now fails in 3.3.4+ versions. Interestingly,
> {code:java}
> Assert.assertTrue(Compare.eq.test(new Double(1.5), new Float(1.5)));
> {code}
> works fine. It seems the problem is coming from the fact that the
> NumberHelper.DOUBLE_NUMBER_HELPER is chosen for the comparison of float and
> double numbers, where
> {code:java}
> new Float(1.53).doubleValue();
> => 1.529713897705
> new Double(1.53).doubleValue();
> => 1.53{code}
> Not sure what the correct implementation here would be, but nonetheless this
> seems to be a backwards incompatible change.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2159) EventStrategy doesn't handle multi-valued properties
Daniel Kuppitz created TINKERPOP-2159: - Summary: EventStrategy doesn't handle multi-valued properties Key: TINKERPOP-2159 URL: https://issues.apache.org/jira/browse/TINKERPOP-2159 Project: TinkerPop Issue Type: Bug Reporter: Daniel Kuppitz Assignee: Daniel Kuppitz As shown [here|https://groups.google.com/d/msgid/gremlin-users/434c5397-c854-4856-ae4a-48146303ae5f%40googlegroups.com?utm_medium=email_source=footer]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2157) SparkStarBarrierInterceptor injects (Byte) 0
[
https://issues.apache.org/jira/browse/TINKERPOP-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz updated TINKERPOP-2157:
--
Summary: SparkStarBarrierInterceptor injects (Byte) 0 (was:
SparkStarBarrierInterceptor injects (Bte) 0)
> SparkStarBarrierInterceptor injects (Byte) 0
>
>
> Key: TINKERPOP-2157
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2157
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.1
>Reporter: Daniel Kuppitz
>Assignee: stephen mallette
>Priority: Major
>
> There are 3 tests that occasionally fail in
> {{SparkGraphComputerProcessIntegrateTest}}:
> * {{g_V_name_min}}
> * {{g_V_name_max}}
> * {{g_V_age_min}}
> In all cases, failure is a result of a mysterious {{(Byte) 0}}. Apparently,
> this zero gets injected by the {{SparkStarBarrierInterceptor}}. I came to
> this conclusion because I wasn't able to reproduce any of the failures after
> excluding this interceptor. However, the failures happen randomly*, so I
> can't say with 100% certainty that the interceptor is the problem.
>
> * on my system it never happened in the Docker builds, rarely in IntelliJ
> debug sessions, but quite often when I just run the test suite in IntelliJ
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2157) SparkStarBarrierInterceptor injects (Bte) 0
Daniel Kuppitz created TINKERPOP-2157:
-
Summary: SparkStarBarrierInterceptor injects (Bte) 0
Key: TINKERPOP-2157
URL: https://issues.apache.org/jira/browse/TINKERPOP-2157
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.4.1
Reporter: Daniel Kuppitz
Assignee: stephen mallette
There are 3 tests that occasionally fail in
{{SparkGraphComputerProcessIntegrateTest}}:
* {{g_V_name_min}}
* {{g_V_name_max}}
* {{g_V_age_min}}
In all cases, failure is a result of a mysterious {{(Byte) 0}}. Apparently,
this zero gets injected by the {{SparkStarBarrierInterceptor}}. I came to this
conclusion because I wasn't able to reproduce any of the failures after
excluding this interceptor. However, the failures happen randomly*, so I can't
say with 100% certainty that the interceptor is the problem.
* on my system it never happened in the Docker builds, rarely in IntelliJ debug
sessions, but quite often when I just run the test suite in IntelliJ
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1882) Apply range and limit steps as early as possible
[
https://issues.apache.org/jira/browse/TINKERPOP-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1882.
-
Resolution: Fixed
Fix Version/s: 3.4.1
3.3.6
> Apply range and limit steps as early as possible
>
>
> Key: TINKERPOP-1882
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1882
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Assignee: Daniel Kuppitz
>Priority: Minor
> Fix For: 3.3.6, 3.4.1
>
>
> For a traversal like
> {{g.V(a).out().valueMap().limit(123)}}
> we can simply move the {{limit()}} to the left so we get:
> {{g.V(a).out().limit(123).valueMap()}}
> This avoids unnecessary database lookups.
> We should create a strategy that moves the {{limit}} and the {{range}} step
> like this to _the left_ for all {{map}} steps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2126) toString() methods not thread-safe
[
https://issues.apache.org/jira/browse/TINKERPOP-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2126.
-
Resolution: Fixed
> toString() methods not thread-safe
> --
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.5
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.6, 3.4.1
>
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the
> internal map, which could concurrently be modified (most likely in OLAP
> environments).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2125) Extend release validation script
[ https://issues.apache.org/jira/browse/TINKERPOP-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz closed TINKERPOP-2125. - Resolution: Fixed Fix Version/s: 3.4.1 3.3.6 > Extend release validation script > > > Key: TINKERPOP-2125 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2125 > Project: TinkerPop > Issue Type: Improvement > Components: build-release >Affects Versions: 3.3.4 >Reporter: Daniel Kuppitz >Assignee: Daniel Kuppitz >Priority: Minor > Fix For: 3.3.6, 3.4.1 > > > Verify that the source distribution doesn't contain any binary files (except > a whitelist of images, icons, kryo files, etc.). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2142) Support named sacks
[
https://issues.apache.org/jira/browse/TINKERPOP-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz updated TINKERPOP-2142:
--
Summary: Support named sacks (was: Support names sacks)
> Support named sacks
> ---
>
> Key: TINKERPOP-2142
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2142
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Reporter: Daniel Kuppitz
>Priority: Major
>
> The queries required to solve the SO question:
> https://stackoverflow.com/questions/54336647/gremlin-query-to-find-connecting-scheduled-flight-routes-filtered-dynamically-on
> require so many state variables, that I really wish we'd have named sacks.
> We would just need to add {{sack(String name)}} and {{sack(String name,
> BiFunction sackOperator)}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2142) Support names sacks
Daniel Kuppitz created TINKERPOP-2142:
-
Summary: Support names sacks
Key: TINKERPOP-2142
URL: https://issues.apache.org/jira/browse/TINKERPOP-2142
Project: TinkerPop
Issue Type: Improvement
Components: process
Reporter: Daniel Kuppitz
The queries required to solve the SO question:
https://stackoverflow.com/questions/54336647/gremlin-query-to-find-connecting-scheduled-flight-routes-filtered-dynamically-on
require so many state variables, that I really wish we'd have named sacks.
We would just need to add {{sack(String name)}} and {{sack(String name,
BiFunction sackOperator)}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2126) toString() methods not thread-safe
[
https://issues.apache.org/jira/browse/TINKERPOP-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz updated TINKERPOP-2126:
--
Summary: toString() methods not thread-safe (was: TraverserSet's
toString() is not thread-safe)
> toString() methods not thread-safe
> --
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.6, 3.4.1
>
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the
> internal map, which could concurrently be modified (most likely in OLAP
> environments).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (TINKERPOP-2126) TraverserSet's toString() is not thread-safe
[
https://issues.apache.org/jira/browse/TINKERPOP-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz reopened TINKERPOP-2126:
---
Reopening as the same issue occurred in {{ObjectWritable}}'s {{toString()}}
method.
> TraverserSet's toString() is not thread-safe
>
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.6, 3.4.1
>
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the
> internal map, which could concurrently be modified (most likely in OLAP
> environments).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2136) Inside lower bound inclusion (documentation)
[
https://issues.apache.org/jira/browse/TINKERPOP-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2136.
-
Resolution: Fixed
Fix Version/s: 3.4.1
3.3.6
> Inside lower bound inclusion (documentation)
>
>
> Key: TINKERPOP-2136
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2136
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.5
>Reporter: Martijn Dwars
>Assignee: Daniel Kuppitz
>Priority: Minor
> Fix For: 3.3.6, 3.4.1
>
>
> On [http://tinkerpop.apache.org/docs/current/reference/#has-step] there is an
> example:
> {code:java}
> g.V().has('age',inside(20,30)).values('age') // 1
> {code}
> with the comment:
> {code:java}
> Find all vertices whose ages are between 20 (inclusive) and 30 (exclusive).
> {code}
> But if I run this in the Gremlin Groovy shell I see:
> {code:java}
> gremlin> g.V().has('age', inside(10, 30)).toString()
> ==>[GraphStep(vertex,[]), HasStep([age.and(gt(10), lt(30))])]
> {code}
> which means the lower bound and upper bound are both exclusive. In
> particular, the lower bound is exclusive, _not_ inclusive. Right?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2136) Inside lower bound inclusion (documentation)
[
https://issues.apache.org/jira/browse/TINKERPOP-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748807#comment-16748807
]
Daniel Kuppitz commented on TINKERPOP-2136:
---
I just go ahead and merge the changes into {{tp33}} and {{master}}. Not worth a
PR as it's just a minor fix in the user docs.
> Inside lower bound inclusion (documentation)
>
>
> Key: TINKERPOP-2136
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2136
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.5
>Reporter: Martijn Dwars
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> On [http://tinkerpop.apache.org/docs/current/reference/#has-step] there is an
> example:
> {code:java}
> g.V().has('age',inside(20,30)).values('age') // 1
> {code}
> with the comment:
> {code:java}
> Find all vertices whose ages are between 20 (inclusive) and 30 (exclusive).
> {code}
> But if I run this in the Gremlin Groovy shell I see:
> {code:java}
> gremlin> g.V().has('age', inside(10, 30)).toString()
> ==>[GraphStep(vertex,[]), HasStep([age.and(gt(10), lt(30))])]
> {code}
> which means the lower bound and upper bound are both exclusive. In
> particular, the lower bound is exclusive, _not_ inclusive. Right?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2124) InlineFilterStrategy produces wrong result
[
https://issues.apache.org/jira/browse/TINKERPOP-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2124.
-
Resolution: Fixed
Fix Version/s: 3.4.1
3.3.6
> InlineFilterStrategy produces wrong result
> --
>
> Key: TINKERPOP-2124
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2124
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.6, 3.4.1
>
>
> {noformat}
> gremlin> g.V().hasLabel("person").
>or(and(has("age",gt(20)),
> has("age",lt(30))),
> and(has("age",gt(35)),
> has("age",lt(40.
> explain()
> ==>Traversal Explanation
> =
> Original Traversal [GraphStep(vertex,[]),
> HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])],
> [HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
> p([age.lt(40)])]])]])]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])],
> [HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
> p([age.lt(40)])]])]])]
> CountStrategy[O] [GraphStep(vertex,[]),
> HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])],
> [HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
> p([age.lt(40)])]])]])]
> MatchPredicateStrategy [O] [GraphStep(vertex,[]),
> HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])],
> [HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
> p([age.lt(40)])]])]])]
> FilterRankingStrategy[O] [GraphStep(vertex,[]),
> HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])],
> [HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
> p([age.lt(40)])]])]])]
> InlineFilterStrategy [O] [GraphStep(vertex,[]),
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> IncidentToAdjacentStrategy [O] [GraphStep(vertex,[]),
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> AdjacentToIncidentStrategy [O] [GraphStep(vertex,[]),
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> RepeatUnrollStrategy [O] [GraphStep(vertex,[]),
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> PathRetractionStrategy [O] [GraphStep(vertex,[]),
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> LazyBarrierStrategy [O] [GraphStep(vertex,[]),
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> TinkerGraphCountStrategy [P] [GraphStep(vertex,[]),
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> TinkerGraphStepStrategy [P]
> [TinkerGraphStep(vertex,[~label.eq(person), age.or(gt(20), lt(30), gt(35),
> lt(40))])]
> ProfileStrategy [F]
> [TinkerGraphStep(vertex,[~label.eq(person), age.or(gt(20), lt(30), gt(35),
> lt(40))])]
> StandardVerificationStrategy [V]
> [TinkerGraphStep(vertex,[~label.eq(person), age.or(gt(20), lt(30), gt(35),
> lt(40))])]
> Final Traversal
> [TinkerGraphStep(vertex,[~label.eq(person), age.or(gt(20), lt(30), gt(35),
> lt(40))])]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2126) TraverserSet's toString() is not thread-safe
[
https://issues.apache.org/jira/browse/TINKERPOP-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2126.
-
Resolution: Fixed
Fix Version/s: 3.4.1
3.3.6
> TraverserSet's toString() is not thread-safe
>
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.6, 3.4.1
>
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the
> internal map, which could concurrently be modified (most likely in OLAP
> environments).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2126) TraverserSet's toString() is not thread-safe
[
https://issues.apache.org/jira/browse/TINKERPOP-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz updated TINKERPOP-2126:
--
Summary: TraverserSet's toString() is not thread-safe (was: TraverserSet's
toString() is no thread-safe)
> TraverserSet's toString() is not thread-safe
>
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the
> internal map, which could concurrently be modified (most likely in OLAP
> environments).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2126) TraverserSet's toString() is no thread-safe
[
https://issues.apache.org/jira/browse/TINKERPOP-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz updated TINKERPOP-2126:
--
Issue Type: Bug (was: Improvement)
> TraverserSet's toString() is no thread-safe
> ---
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the
> internal map, which could concurrently be modified (most likely in OLAP
> environments).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2126) TraverserSet's toString() is no thread-safe
Daniel Kuppitz created TINKERPOP-2126:
-
Summary: TraverserSet's toString() is no thread-safe
Key: TINKERPOP-2126
URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
Project: TinkerPop
Issue Type: Improvement
Components: process
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
{{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the
internal map, which could concurrently be modified (most likely in OLAP
environments).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2125) Extend release validation script
Daniel Kuppitz created TINKERPOP-2125: - Summary: Extend release validation script Key: TINKERPOP-2125 URL: https://issues.apache.org/jira/browse/TINKERPOP-2125 Project: TinkerPop Issue Type: Improvement Components: build-release Reporter: Daniel Kuppitz Assignee: Daniel Kuppitz Verify that the source distribution doesn't contain any binary files (except a whitelist of images, icons, kryo files, etc.). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2124) InlineFilterStrategy produces wrong result
Daniel Kuppitz created TINKERPOP-2124:
-
Summary: InlineFilterStrategy produces wrong result
Key: TINKERPOP-2124
URL: https://issues.apache.org/jira/browse/TINKERPOP-2124
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.3.4
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
{noformat}
gremlin> g.V().hasLabel("person").
or(and(has("age",gt(20)),
has("age",lt(30))),
and(has("age",gt(35)),
has("age",lt(40.
explain()
==>Traversal Explanation
=
Original Traversal [GraphStep(vertex,[]),
HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])],
[HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
p([age.lt(40)])]])]])]
ConnectiveStrategy [D] [GraphStep(vertex,[]),
HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])],
[HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
p([age.lt(40)])]])]])]
CountStrategy[O] [GraphStep(vertex,[]),
HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])],
[HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
p([age.lt(40)])]])]])]
MatchPredicateStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])],
[HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
p([age.lt(40)])]])]])]
FilterRankingStrategy[O] [GraphStep(vertex,[]),
HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])],
[HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
p([age.lt(40)])]])]])]
InlineFilterStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
IncidentToAdjacentStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
AdjacentToIncidentStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
RepeatUnrollStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
PathRetractionStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
LazyBarrierStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
TinkerGraphCountStrategy [P] [GraphStep(vertex,[]),
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
TinkerGraphStepStrategy [P] [TinkerGraphStep(vertex,[~label.eq(person),
age.or(gt(20), lt(30), gt(35), lt(40))])]
ProfileStrategy [F] [TinkerGraphStep(vertex,[~label.eq(person),
age.or(gt(20), lt(30), gt(35), lt(40))])]
StandardVerificationStrategy [V] [TinkerGraphStep(vertex,[~label.eq(person),
age.or(gt(20), lt(30), gt(35), lt(40))])]
Final Traversal[TinkerGraphStep(vertex,[~label.eq(person),
age.or(gt(20), lt(30), gt(35), lt(40))])]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1849) Provide a way to fold() with an index
[
https://issues.apache.org/jira/browse/TINKERPOP-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1849.
-
Resolution: Fixed
Fix Version/s: 3.4.0
> Provide a way to fold() with an index
> -
>
> Key: TINKERPOP-1849
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1849
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0
>
>
> In Groovy you can call {{withIndex()}} to generate output like this:
> {code}
> gremlin> g.V().fold().next().withIndex()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> We can currently simulate this with Gremlin via:
> {code}
> gremlin>
> g.V().project("a","b").by().by(select("x").count(local)).store("x").map(union(select('a'),
> select('b')).fold()).fold().next()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> but it's not easy to follow, efficient, or potentially foolproof. Perhaps we
> can add an option to {{fold()}} that would take an enum of "fold operators".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2114) Document common Gremlin anti-patterns
[ https://issues.apache.org/jira/browse/TINKERPOP-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz closed TINKERPOP-2114. - Resolution: Fixed Fix Version/s: 3.3.5 3.4.0 > Document common Gremlin anti-patterns > - > > Key: TINKERPOP-2114 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2114 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.3.4 >Reporter: Daniel Kuppitz >Assignee: Daniel Kuppitz >Priority: Major > Fix For: 3.4.0, 3.3.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2114) Document common Gremlin anti-patterns
Daniel Kuppitz created TINKERPOP-2114: - Summary: Document common Gremlin anti-patterns Key: TINKERPOP-2114 URL: https://issues.apache.org/jira/browse/TINKERPOP-2114 Project: TinkerPop Issue Type: Improvement Components: documentation Affects Versions: 3.3.4 Reporter: Daniel Kuppitz Assignee: Daniel Kuppitz -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2112) Folding in property() step is screwed
Daniel Kuppitz created TINKERPOP-2112:
-
Summary: Folding in property() step is screwed
Key: TINKERPOP-2112
URL: https://issues.apache.org/jira/browse/TINKERPOP-2112
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.3.4
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
Somehow we mess up the folding in {{property()}} step when it's used with
tokens. I think there's just a missing {{if}} branch, but needs further
investigation.
{noformat}
gremlin> g = TinkerGraph.open().traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.addV().property(T.id , 'id').property(single, 'k', 'v')
==>v[id]
gremlin> g.addV().property(single, 'k', 'v').property(T.id , 'id')
org.apache.tinkerpop.gremlin.structure.T$2 cannot be cast to java.lang.String
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}
{noformat}
gremlin> g = TinkerGraph.open().traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.addV().property(T.id , 'id').property(single, 'k', 'v').explain()
==>Traversal Explanation
=
Original Traversal [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
ConnectiveStrategy [D] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
MatchPredicateStrategy [O] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
FilterRankingStrategy[O] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
InlineFilterStrategy [O] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
IncidentToAdjacentStrategy [O] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
AdjacentToIncidentStrategy [O] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
RepeatUnrollStrategy [O] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
PathRetractionStrategy [O] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
CountStrategy[O] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
LazyBarrierStrategy [O] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
TinkerGraphCountStrategy [P] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
TinkerGraphStepStrategy [P] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
ProfileStrategy [F] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
StandardVerificationStrategy [V] [AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
Final Traversal[AddVertexStartStep({id=[id]}),
AddPropertyStep({key=[k], value=[v]})]
gremlin> g.addV().property(single, 'k', 'v').property(T.id , 'id').explain()
==>Traversal Explanation
===
Original Traversal [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
ConnectiveStrategy [D] [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
MatchPredicateStrategy [O] [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
FilterRankingStrategy[O] [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
InlineFilterStrategy [O] [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
IncidentToAdjacentStrategy [O] [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
AdjacentToIncidentStrategy [O] [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
RepeatUnrollStrategy [O] [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
PathRetractionStrategy [O] [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
CountStrategy[O] [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
LazyBarrierStrategy [O] [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
TinkerGraphCountStrategy [P] [AddVertexStartStep({}),
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id],
[jira] [Comment Edited] (TINKERPOP-1849) Provide a way to fold() with an index
[
https://issues.apache.org/jira/browse/TINKERPOP-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680108#comment-16680108
]
Daniel Kuppitz edited comment on TINKERPOP-1849 at 12/4/18 9:58 PM:
I don't know when I will start to work on this, so - as a reminder - here are
just the thoughts from our latest discussion:
We should only implement a local version of this step, because
# it's not too much to ask a user to do the {{fold()}}
# by explicitly using {{fold()}} the user is made aware of the memory
consumption
# it will just work in OLTP and OLAP
This is how could look like:
{noformat}
gremlin> g.V().index()
==>[v[1], 0]
==>[v[2], 0]
==>[v[3], 0]
==>[v[4], 0]
==>[v[5], 0]
==>[v[6], 0]
gremlin> g.V().fold().index()
==>[[v[1],0],[v[2],1],[v[3],2],[v[4],3],[v[5],4],[v[6],5]]
gremlin> g.V().fold().index().with(WithOptions.indexer, WithOptions.map)
==>[0:v[1],1:v[2],2:v[3],3:v[4],4:v[5],5:v[6]]
{noformat}
was (Author: dkuppitz):
I don't know when I will start to work on this, so - as a reminder - here are
just the thoughts from our latest discussion:
We should only implement a local version of this step, because
# it's not too much to ask a user to do the {{fold()}}
# by explicitly using {{fold()}} the user is made aware of the memory
consumption
# it will just work in OLTP and OLAP
This is how could look like:
{noformat}
gremlin> g.V().index()
==>[v[1], 0]
==>[v[2], 0]
==>[v[3], 0]
==>[v[4], 0]
==>[v[5], 0]
==>[v[6], 0]
gremlin> g.V().fold().index()
==>[[v[1],0],[v[2],1],[v[3],2],[v[4],3],[v[5],4],[v[6],5]]
gremlin> g.V().fold().index().by('e').by('i')
==>[[e:v[1],i:0],[e:v[2],i:1],[e:v[3],i:2],[e:v[4],i:3],[e:v[5],i:4],[e:v[6],i:5]]
{noformat}
> Provide a way to fold() with an index
> -
>
> Key: TINKERPOP-1849
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1849
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
>
> In Groovy you can call {{withIndex()}} to generate output like this:
> {code}
> gremlin> g.V().fold().next().withIndex()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> We can currently simulate this with Gremlin via:
> {code}
> gremlin>
> g.V().project("a","b").by().by(select("x").count(local)).store("x").map(union(select('a'),
> select('b')).fold()).fold().next()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> but it's not easy to follow, efficient, or potentially foolproof. Perhaps we
> can add an option to {{fold()}} that would take an enum of "fold operators".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2100) coalesce() creating unexpected results when used with order()
[
https://issues.apache.org/jira/browse/TINKERPOP-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2100.
-
Resolution: Fixed
Fix Version/s: 3.3.5
3.4.0
> coalesce() creating unexpected results when used with order()
> -
>
> Key: TINKERPOP-2100
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2100
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.4
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0, 3.3.5
>
>
> Bug was originally reported here:
> https://stackoverflow.com/q/53482054/1831717
> demonstrated as:
> {code}
> gremlin> g.V().
> ..1> hasLabel("person").
> ..2> out("created").
> ..3> order().by("name").
> ..4> coalesce(values("name").fold(), constant("x")).
> ..5> fold()
> ==>[[lop,lop,lop],[lop,lop,lop],[lop,lop,lop],[ripple]]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2107) Spark fails to reattach properties
Daniel Kuppitz created TINKERPOP-2107:
-
Summary: Spark fails to reattach properties
Key: TINKERPOP-2107
URL: https://issues.apache.org/jira/browse/TINKERPOP-2107
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.3.4
Reporter: Daniel Kuppitz
The traversal {{g.V().outE().properties().dedup()}} throws a
{{NullPointerException}} when run in Spark OLAP. I created a branch for this
ticket and added a failing test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2095) GroupStep looks for irrelevant barrier steps
[
https://issues.apache.org/jira/browse/TINKERPOP-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2095.
-
Resolution: Fixed
Fix Version/s: 3.3.5
3.4.0
> GroupStep looks for irrelevant barrier steps
>
>
> Key: TINKERPOP-2095
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2095
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0, 3.3.5
>
>
> {{GroupStep}} looks for a {{Barrier}} step to determine the reducing
> bi-operator. This is wrong and I'm really surprised that this has never been
> spotted before.
> {noformat}
> gremlin>
> g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
> java.lang.Long cannot be cast to
> org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}
> In the query above the first barrier step is a {{NoOpBarrier}} step (added by
> {{PathRetractionStrategy}}). This step obviously has no reducing bi-operator.
> What we really want to do is look for the first barrier step that is not a
> {{LocalBarrier}} step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2095) GroupStep looks for irrelevant barrier steps
[
https://issues.apache.org/jira/browse/TINKERPOP-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz updated TINKERPOP-2095:
--
Description:
{{GroupStep}} looks for a {{Barrier}} step to determine the reducing
bi-operator. This is wrong and I'm really surprised that this has never been
spotted before.
{noformat}
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
java.lang.Long cannot be cast to
org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}
In the query above the first barrier step is a {{NoOpBarrier}} step (added by
{{PathRetractionStrategy}}). This step obviously has no reducing bi-operator.
What we really want to do is look for the first barrier step that is not a
{{LocalBarrier}} step.
was:
{{GroupStep}} looks for {{Barrier}} step to determine the reducing bi-operator.
This is wrong and I'm really surprised that this has never been spotted before.
{noformat}
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
java.lang.Long cannot be cast to
org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}
In the query above the first barrier step is a {{NoOpBarrier}} step (added by
{{PathRetractionStrategy}}). This step obviously has no reducing bi-operator.
What we really want to do is look for the first reducing barrier step.
> GroupStep looks for irrelevant barrier steps
>
>
> Key: TINKERPOP-2095
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2095
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> {{GroupStep}} looks for a {{Barrier}} step to determine the reducing
> bi-operator. This is wrong and I'm really surprised that this has never been
> spotted before.
> {noformat}
> gremlin>
> g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
> java.lang.Long cannot be cast to
> org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}
> In the query above the first barrier step is a {{NoOpBarrier}} step (added by
> {{PathRetractionStrategy}}). This step obviously has no reducing bi-operator.
> What we really want to do is look for the first barrier step that is not a
> {{LocalBarrier}} step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2095) GroupStep looks for irrelevant barrier steps
Daniel Kuppitz created TINKERPOP-2095:
-
Summary: GroupStep looks for irrelevant barrier steps
Key: TINKERPOP-2095
URL: https://issues.apache.org/jira/browse/TINKERPOP-2095
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.3.4
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
{{GroupStep}} looks for {{Barrier}} step to determine the reducing bi-operator.
This is wrong and I'm really surprised that this has never been spotted before.
{noformat}
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
java.lang.Long cannot be cast to
org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}
In the query above the first barrier step is a {{NoOpBarrier}} step (added by
{{PathRetractionStrategy}}). This step obviously has no reducing bi-operator.
What we really want to do is look for the first reducing barrier step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (TINKERPOP-2051) Uniqueness of property ids
[ https://issues.apache.org/jira/browse/TINKERPOP-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz reassigned TINKERPOP-2051: - Assignee: Daniel Kuppitz > Uniqueness of property ids > -- > > Key: TINKERPOP-2051 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2051 > Project: TinkerPop > Issue Type: Bug > Components: structure >Affects Versions: 3.2.9 >Reporter: Daniel Kuppitz >Assignee: Daniel Kuppitz >Priority: Major > Labels: breaking > > Right now we don't ensure property id uniqueness. As shown in [this > discussion|https://lists.apache.org/thread.html/e28d61e1f3b674b617765a0f28174d45691db0812e7c56761d1456c3@%3Cdev.tinkerpop.apache.org%3E], > this can lead to very odd results, hence I marked this ticket as a Bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2059) Modulation of valueMap()
[
https://issues.apache.org/jira/browse/TINKERPOP-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2059.
-
Resolution: Fixed
Fix Version/s: 3.4.0
> Modulation of valueMap()
>
>
> Key: TINKERPOP-2059
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2059
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.3
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
> Labels: breaking
> Fix For: 3.4.0
>
>
> Allow for modulation of the {{valueMap()}} step with {{by()}} and possibly
> {{with()}} to make it's usage more flexible and consistent. The problem
> presented in relation to this change is how to easily unwrap the general
> multi-property structure of {{valueMap()}}
> {code}
> g.V().has('person','name','marko').
> valueMap('name','age').
> by(unfold())
> {code}
> which would yield: {{[name:marko,age:29]}} rather than:
> {{[name:[marko],age:[29]]}}. Obviously the {{by()}} is just a map over the
> values in the list of values returned from properties.
> Please see the
> [DISCUSS|https://lists.apache.org/thread.html/91a3c980b5968c78638383dfa11f44ee14fc114ddc3d29e762e56f1f@%3Cdev.tinkerpop.apache.org%3E]
> thread for additional thoughts on the matter to consider.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1849) Provide a way to fold() with an index
[
https://issues.apache.org/jira/browse/TINKERPOP-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680108#comment-16680108
]
Daniel Kuppitz commented on TINKERPOP-1849:
---
I don't know when I will start to work on this, so - as a reminder - here are
just the thoughts from our latest discussion:
We should only implement a local version of this step, because
# it's not too much to ask a user to do the {{fold()}}
# by explicitly using {{fold()}} the user is made aware of the memory
consumption
# it will just work in OLTP and OLAP
This is how could look like:
{noformat}
gremlin> g.V().index()
==>[v[1], 0]
==>[v[2], 0]
==>[v[3], 0]
==>[v[4], 0]
==>[v[5], 0]
==>[v[6], 0]
gremlin> g.V().fold().index()
==>[[v[1],0],[v[2],1],[v[3],2],[v[4],3],[v[5],4],[v[6],5]]
gremlin> g.V().fold().index().by('e').by('i')
==>[[e:v[1],i:0],[e:v[2],i:1],[e:v[3],i:2],[e:v[4],i:3],[e:v[5],i:4],[e:v[6],i:5]]
{noformat}
> Provide a way to fold() with an index
> -
>
> Key: TINKERPOP-1849
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1849
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
>
> In Groovy you can call {{withIndex()}} to generate output like this:
> {code}
> gremlin> g.V().fold().next().withIndex()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> We can currently simulate this with Gremlin via:
> {code}
> gremlin>
> g.V().project("a","b").by().by(select("x").count(local)).store("x").map(union(select('a'),
> select('b')).fold()).fold().next()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> but it's not easy to follow, efficient, or potentially foolproof. Perhaps we
> can add an option to {{fold()}} that would take an enum of "fold operators".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2059) Modulation of valueMap()
[
https://issues.apache.org/jira/browse/TINKERPOP-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz updated TINKERPOP-2059:
--
Labels: breaking (was: )
> Modulation of valueMap()
>
>
> Key: TINKERPOP-2059
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2059
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.3
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
> Labels: breaking
>
> Allow for modulation of the {{valueMap()}} step with {{by()}} and possibly
> {{with()}} to make it's usage more flexible and consistent. The problem
> presented in relation to this change is how to easily unwrap the general
> multi-property structure of {{valueMap()}}
> {code}
> g.V().has('person','name','marko').
> valueMap('name','age').
> by(unfold())
> {code}
> which would yield: {{[name:marko,age:29]}} rather than:
> {{[name:[marko],age:[29]]}}. Obviously the {{by()}} is just a map over the
> values in the list of values returned from properties.
> Please see the
> [DISCUSS|https://lists.apache.org/thread.html/91a3c980b5968c78638383dfa11f44ee14fc114ddc3d29e762e56f1f@%3Cdev.tinkerpop.apache.org%3E]
> thread for additional thoughts on the matter to consider.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2062) Add Traversal class to CoreImports
[
https://issues.apache.org/jira/browse/TINKERPOP-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2062.
-
Resolution: Fixed
Fix Version/s: 3.3.5
3.4.0
> Add Traversal class to CoreImports
> --
>
> Key: TINKERPOP-2062
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2062
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.3.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Minor
> Fix For: 3.4.0, 3.3.5
>
>
> Apparently, some people like to copy Gremlin queries they've written in Java
> and paste them into the Gremlin console. This should usually work pretty
> well, however, there are some oddities in particular with {{union()}} step
> which requires you to cast the child traversals to {{Traversal}} if they have
> different return types, e.g.:
> {noformat}
> g.V().
> union(
> __.identity(),
> (Traversal)__.outE()
> )
> {noformat}
> This works in a local console session but fails if the query is sent to a
> server as {{Traversal}} is not part of the core imports.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2073) Generate tabs for static code blocks
[
https://issues.apache.org/jira/browse/TINKERPOP-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16657171#comment-16657171
]
Daniel Kuppitz commented on TINKERPOP-2073:
---
Proposed solution:
{noformat}
[source,java,tab]
Vertex v =
[source,python]
v =
[source,javascript]
const v =
{noformat}
If the first static code block contains the {{tab}} argument, this block and
all the following code blocks will be tabified.
> Generate tabs for static code blocks
>
>
> Key: TINKERPOP-2073
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2073
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.4.0
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> Tabs are only generated for evaluated code blocks. It should be possible to
> tabify static code blocks, too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2073) Generate tabs for static code blocks
Daniel Kuppitz created TINKERPOP-2073: - Summary: Generate tabs for static code blocks Key: TINKERPOP-2073 URL: https://issues.apache.org/jira/browse/TINKERPOP-2073 Project: TinkerPop Issue Type: Improvement Components: documentation Affects Versions: 3.4.0 Reporter: Daniel Kuppitz Assignee: Daniel Kuppitz Tabs are only generated for evaluated code blocks. It should be possible to tabify static code blocks, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2058) Contains predicates should rely on Compare predicates
[
https://issues.apache.org/jira/browse/TINKERPOP-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2058.
-
Resolution: Fixed
Fix Version/s: 3.4.0
> Contains predicates should rely on Compare predicates
> -
>
> Key: TINKERPOP-2058
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2058
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.0
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Labels: breaking
> Fix For: 3.4.0
>
>
> The problem:
> {noformat}
> gremlin> g.V().has("age", eq(32L))
> ==>v[4]
> gremlin> g.V().has("age", within(32L, 35L))
> gremlin>
> {noformat}
> {{Contains}} predicates should really behave the same way {{Compare}}
> predicates do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-2062) Add Traversal class to CoreImports
[
https://issues.apache.org/jira/browse/TINKERPOP-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646628#comment-16646628
]
Daniel Kuppitz edited comment on TINKERPOP-2062 at 10/11/18 3:35 PM:
-
I tried, but couldn't figure out how.
was (Author: dkuppitz):
I tried, but couldn't figure out why.
> Add Traversal class to CoreImports
> --
>
> Key: TINKERPOP-2062
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2062
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.3.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> Apparently, some people like to copy Gremlin queries they've written in Java
> and paste them into the Gremlin console. This should usually work pretty
> well, however, there are some oddities in particular with {{union()}} step
> which requires you to cast the child traversals to {{Traversal}} if they have
> different return types, e.g.:
> {noformat}
> g.V().
> union(
> __.identity(),
> (Traversal)__.outE()
> )
> {noformat}
> This works in a local console session but fails if the query is sent to a
> server as {{Traversal}} is not part of the core imports.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2062) Add Traversal class to CoreImports
[
https://issues.apache.org/jira/browse/TINKERPOP-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646628#comment-16646628
]
Daniel Kuppitz commented on TINKERPOP-2062:
---
I tried, but couldn't figure out why.
> Add Traversal class to CoreImports
> --
>
> Key: TINKERPOP-2062
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2062
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.3.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> Apparently, some people like to copy Gremlin queries they've written in Java
> and paste them into the Gremlin console. This should usually work pretty
> well, however, there are some oddities in particular with {{union()}} step
> which requires you to cast the child traversals to {{Traversal}} if they have
> different return types, e.g.:
> {noformat}
> g.V().
> union(
> __.identity(),
> (Traversal)__.outE()
> )
> {noformat}
> This works in a local console session but fails if the query is sent to a
> server as {{Traversal}} is not part of the core imports.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2062) Add Traversal class to CoreImports
Daniel Kuppitz created TINKERPOP-2062:
-
Summary: Add Traversal class to CoreImports
Key: TINKERPOP-2062
URL: https://issues.apache.org/jira/browse/TINKERPOP-2062
Project: TinkerPop
Issue Type: Improvement
Components: server
Affects Versions: 3.3.3
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
Apparently, some people like to copy Gremlin queries they've written in Java
and paste them into the Gremlin console. This should usually work pretty well,
however, there are some oddities in particular with {{union()}} step which
requires you to cast the child traversals to {{Traversal}} if they have
different return types, e.g.:
{noformat}
g.V().
union(
__.identity(),
(Traversal)__.outE()
)
{noformat}
This works in a local console session but fails if the query is sent to a
server as {{Traversal}} is not part of the core imports.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2056) Use NumberHelper in Compare
[
https://issues.apache.org/jira/browse/TINKERPOP-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2056.
-
Resolution: Fixed
Fix Version/s: 3.2.10
3.3.4
3.4.0
> Use NumberHelper in Compare
> ---
>
> Key: TINKERPOP-2056
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2056
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.9
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0, 3.3.4, 3.2.10
>
>
> The {{Compare}} enum doesn't use {{NumberHelper}}. Instead, it converts
> numbers of differing types to {{BigDecimal}}s. That's pretty much the slowest
> thing we can do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2041) Text Predicates
[
https://issues.apache.org/jira/browse/TINKERPOP-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2041.
-
Resolution: Fixed
Fix Version/s: 3.4.0
> Text Predicates
> ---
>
> Key: TINKERPOP-2041
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2041
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.4.0
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0
>
>
> Provide these simple text predicates:
> * {{startsWith}}
> * {{endsWith}}
> * {{contains}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2058) Contains predicates should rely on Compare predicates
Daniel Kuppitz created TINKERPOP-2058:
-
Summary: Contains predicates should rely on Compare predicates
Key: TINKERPOP-2058
URL: https://issues.apache.org/jira/browse/TINKERPOP-2058
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.4.0
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
The problem:
{noformat}
gremlin> g.V().has("age", eq(32L))
==>v[4]
gremlin> g.V().has("age", within(32L, 35L))
gremlin>
{noformat}
{{Contains}} predicates should really behave the same way {{Compare}}
predicates do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2056) Use NumberHelper in Compare
[
https://issues.apache.org/jira/browse/TINKERPOP-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637280#comment-16637280
]
Daniel Kuppitz commented on TINKERPOP-2056:
---
Kinda related: {{Contains}} doesn't convert differing number types at all.
{noformat}
gremlin> g.V().has("age", eq(32L))
==>v[4]
gremlin> g.V().has("age", within(32L, 35L))
gremlin>
{noformat}
The problem though: This behavior is enforced by the test suite and a change
would be breaking. Hence I'm going to include the {{Compare}} changes in the
{{tp32}} PR and I will create another PR for {{master/}} that also includes the
{{Contains}} changes.
> Use NumberHelper in Compare
> ---
>
> Key: TINKERPOP-2056
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2056
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.9
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> The {{Compare}} enum doesn't use {{NumberHelper}}. Instead, it converts
> numbers of differing types to {{BigDecimal}}s. That's pretty much the slowest
> thing we can do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2056) Use NumberHelper in Compare
Daniel Kuppitz created TINKERPOP-2056:
-
Summary: Use NumberHelper in Compare
Key: TINKERPOP-2056
URL: https://issues.apache.org/jira/browse/TINKERPOP-2056
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.2.9
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
The {{Compare}} enum doesn't use {{NumberHelper}}. Instead, it converts numbers
of differing types to {{BigDecimal}}s. That's pretty much the slowest thing we
can do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2025) Change to SHA-256/512 and drop SHA-1 for releases
[ https://issues.apache.org/jira/browse/TINKERPOP-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz closed TINKERPOP-2025. - Resolution: Fixed Fix Version/s: 3.2.10 3.3.4 3.4.0 > Change to SHA-256/512 and drop SHA-1 for releases > - > > Key: TINKERPOP-2025 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2025 > Project: TinkerPop > Issue Type: Improvement > Components: build-release >Affects Versions: 3.2.9 >Reporter: stephen mallette >Assignee: Daniel Kuppitz >Priority: Critical > Fix For: 3.4.0, 3.3.4, 3.2.10 > > > Given changes to Apache build requirements it seems we need to adjust our > release process again: > https://www.apache.org/dev/release-distribution#sigs-and-sums > Note that it appears the apache parent pom has updates to consider in this > regard: > https://issues.apache.org/jira/browse/MPOM-205 > Official release information is here: > https://s.apache.org/asf-pom-21 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2041) Text Predicates
Daniel Kuppitz created TINKERPOP-2041:
-
Summary: Text Predicates
Key: TINKERPOP-2041
URL: https://issues.apache.org/jira/browse/TINKERPOP-2041
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.4.0
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
Provide these simple text predicates:
* {{startsWith}}
* {{endsWith}}
* {{contains}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2029) ConcurrentModificationException for InlineFilterStrategy
[
https://issues.apache.org/jira/browse/TINKERPOP-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2029.
-
Resolution: Fixed
Fix Version/s: 3.4.0
> ConcurrentModificationException for InlineFilterStrategy
>
>
> Key: TINKERPOP-2029
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2029
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Minor
> Fix For: 3.4.0
>
>
> {code}
> gremlin> g.V().has("name", "marko").and().has("name",
> "marko").and().has("name", "marko")
> java.util.ConcurrentModificationException
> Type ':help' or ':h' for help.
> Display stack trace? [yN]y
> java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
> at java.util.ArrayList$Itr.next(ArrayList.java:859)
> at
> java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1042)
> at
> org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization.InlineFilterStrategy.processHasStep(InlineFilterStrategy.java:114)
> at
> org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization.InlineFilterStrategy.apply(InlineFilterStrategy.java:93)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.TraversalHelper.applySingleLevelStrategies(TraversalHelper.java:696)
> at
> org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization.InlineFilterStrategy.processAndStep(InlineFilterStrategy.java:248)
> at
> org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization.InlineFilterStrategy.apply(InlineFilterStrategy.java:96)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversalStrategies.applyStrategies(DefaultTraversalStrategies.java:86)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.applyStrategies(DefaultTraversal.java:119)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:191)
> at
> org.apache.tinkerpop.gremlin.console.Console$_closure3.doCall(Console.groovy:239)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
> at
> org.codehaus.groovy.tools.shell.Groovysh.setLastResult(Groovysh.groovy:460)
> at org.codehaus.groovy.tools.shell.Groovysh.execute(Groovysh.groovy:196)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.super$3$execute(GremlinGroovysh.groovy)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1225)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:145)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.execute(GremlinGroovysh.groovy:72)
> at org.codehaus.groovy.tools.shell.Shell.leftShift(Shell.groovy:122)
> at
> org.codehaus.groovy.tools.shell.ShellRunner.work(ShellRunner.groovy:95)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$work(InteractiveShellRunner.groovy)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1225)
> at
>
[jira] [Closed] (TINKERPOP-1990) Add a shortestPath() step
[
https://issues.apache.org/jira/browse/TINKERPOP-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1990.
-
Resolution: Fixed
Fix Version/s: 3.4.0
> Add a shortestPath() step
> -
>
> Key: TINKERPOP-1990
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1990
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0
>
>
> Implement {{ShortestPathVertexProgram}} and a {{shortestPath()}} step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1298) Save OLAP results to file
[
https://issues.apache.org/jira/browse/TINKERPOP-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16562256#comment-16562256
]
Daniel Kuppitz commented on TINKERPOP-1298:
---
Gotcha. Yes, I think that makes sense.
> Save OLAP results to file
> -
>
> Key: TINKERPOP-1298
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1298
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, process
>Affects Versions: 3.2.5
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> Provide a way to save (tabular) results to text files, just like Spark's
> {{saveAsTextFile}}.
> I'm not sure about the best way to do it. 3 options come to my mind:
> # a new step.
> # a {{VertexProgram}}
> # a configuration option
> Things to consider / open questions:
> * Is it sufficient to simply {{toString()}} all values or should we allow
> formatters / format stings?
> * [~jlewandowski] pointed out that it would be nice to have support for the
> [parquet file format|https://parquet.apache.org/]. I guess now we're already
> talking about support for different {{FileOutputFormats}} and not just
> formatters.
> * Is that only relevant for OLAP?
> * Can we support arbitrary file systems?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1298) Save OLAP results to file
[
https://issues.apache.org/jira/browse/TINKERPOP-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561212#comment-16561212
]
Daniel Kuppitz commented on TINKERPOP-1298:
---
Oh, I didn't realize that it can do that, I thought it can only handle graphs.
I need to play with it, but if it works as shown in your snippet, then that's
that.
> Save OLAP results to file
> -
>
> Key: TINKERPOP-1298
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1298
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, process
>Affects Versions: 3.2.5
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> Provide a way to save (tabular) results to text files, just like Spark's
> {{saveAsTextFile}}.
> I'm not sure about the best way to do it. 3 options come to my mind:
> # a new step.
> # a {{VertexProgram}}
> # a configuration option
> Things to consider / open questions:
> * Is it sufficient to simply {{toString()}} all values or should we allow
> formatters / format stings?
> * [~jlewandowski] pointed out that it would be nice to have support for the
> [parquet file format|https://parquet.apache.org/]. I guess now we're already
> talking about support for different {{FileOutputFormats}} and not just
> formatters.
> * Is that only relevant for OLAP?
> * Can we support arbitrary file systems?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1298) Save OLAP results to file
[
https://issues.apache.org/jira/browse/TINKERPOP-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560587#comment-16560587
]
Daniel Kuppitz commented on TINKERPOP-1298:
---
I don't think it's related as this is not about writing a graph, but the actual
result of a query.
> Save OLAP results to file
> -
>
> Key: TINKERPOP-1298
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1298
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, process
>Affects Versions: 3.2.5
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> Provide a way to save (tabular) results to text files, just like Spark's
> {{saveAsTextFile}}.
> I'm not sure about the best way to do it. 3 options come to my mind:
> # a new step.
> # a {{VertexProgram}}
> # a configuration option
> Things to consider / open questions:
> * Is it sufficient to simply {{toString()}} all values or should we allow
> formatters / format stings?
> * [~jlewandowski] pointed out that it would be nice to have support for the
> [parquet file format|https://parquet.apache.org/]. I guess now we're already
> talking about support for different {{FileOutputFormats}} and not just
> formatters.
> * Is that only relevant for OLAP?
> * Can we support arbitrary file systems?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1992) count has negative time in profile
[
https://issues.apache.org/jira/browse/TINKERPOP-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555871#comment-16555871
]
Daniel Kuppitz commented on TINKERPOP-1992:
---
It actually happens to any reducing step in {{group()}}'s value selector.
{code}
gremlin> g.V().group().by().by(bothE().fold()).profile()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
TinkerGraphStep(vertex,[]) 6
6 0.05313.94
GroupStep(identity,[VertexStep(BOTH,edge), Prof... 1
1 0.32986.06
VertexStep(BOTH,edge) 12
12 0.084
FoldStep 6
6 -0.063
>TOTAL -
- 0.383-
gremlin> g.V().group().by().by(bothE().values('weight').sum()).profile()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
TinkerGraphStep(vertex,[]) 6
6 0.05810.54
GroupStep(identity,[VertexStep(BOTH,edge), Prof... 1
1 0.49289.46
VertexStep(BOTH,edge) 12
12 0.104
PropertiesStep([weight],value) 12
12 0.086
SumGlobalStep6
6 -0.160
>TOTAL -
- 0.550-
{code}
> count has negative time in profile
> --
>
> Key: TINKERPOP-1992
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1992
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Robert Dale
>Priority: Minor
>
> {noformat}
> gremlin> g.V().group().by().by(bothE().count()).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 19172
> 19172 4.957 5.24
> GroupStep(identity,[VertexStep(BOTH,edge), Prof... 1
> 1 89.69694.76
> VertexStep(BOTH,edge)84812
> 84812 50.723
> CountGlobalStep 19172
> 19172 -39.649
> >TOTAL -
> - 94.654-
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2011) Use NumberHelper on choose()
[
https://issues.apache.org/jira/browse/TINKERPOP-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2011.
-
Resolution: Fixed
Fix Version/s: 3.2.10
3.3.4
3.4.0
> Use NumberHelper on choose()
>
>
> Key: TINKERPOP-2011
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2011
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Minor
> Fix For: 3.4.0, 3.3.4, 3.2.10
>
>
> The {{choose()} step could use {{NumberHelper}} to make this easier:
> {code}
> gremlin> g.V(1).choose(values('b')).option(b,
> constant(true)).option(none,constant(false))
> ==>true
> gremlin> g.V(1).choose(values('b')).option(1,
> constant(true)).option(none,constant(false))
> ==>false
> gremlin> g.V(1).choose(values('b')).option(1 as byte,
> constant(true)).option(none,constant(false))
> ==>true
> {code}
> as discussed here:
> https://groups.google.com/d/msg/gremlin-users/4pjH7AOM72s/ohIEdABfBQAJ
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-1990) Add a shortestPath() step
Daniel Kuppitz created TINKERPOP-1990:
-
Summary: Add a shortestPath() step
Key: TINKERPOP-1990
URL: https://issues.apache.org/jira/browse/TINKERPOP-1990
Project: TinkerPop
Issue Type: Improvement
Components: process
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
Implement {{ShortestPathVertexProgram}} and a {{shortestPath()}} step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1643) Something's broke in OLAP
[
https://issues.apache.org/jira/browse/TINKERPOP-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516367#comment-16516367
]
Daniel Kuppitz commented on TINKERPOP-1643:
---
Done. Rebased and force-pushed.
> Something's broke in OLAP
> -
>
> Key: TINKERPOP-1643
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1643
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.0, 3.2.5
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
>Priority: Major
>
> I don't know what it's related to, hence the open title on this ticket.
> *Base Query (all good)*:
> {noformat}
> gremlin> g.V().as("v").emit().repeat(both().as("v").dedup()).select("v")
> ==>v[1]
> ==>v[2]
> ==>v[3]
> ==>v[4]
> ==>v[5]
> ==>v[6]
> ==>[v[1],v[4]]
> ==>[v[4],v[5]]
> ==>[v[3],v[6]]
> ==>[v[2],v[1]]
> ==>[v[1],v[2]]
> ==>[v[1],v[3]]
> {noformat}
> *Issues*:
> {noformat}
> gremlin>
> g.V().as("v").emit().repeat(both().as("v").dedup()).select("v").count()
> ==>6
> ==>6
> {noformat}
> {noformat}
> gremlin>
> g.V().as("v").emit().repeat(both().as("v").dedup()).select("v").order().by(count(local))
> ==>v[1]
> ==>v[1]
> ==>v[2]
> ==>v[2]
> ==>v[3]
> ==>v[3]
> ==>v[4]
> ==>v[4]
> ==>v[5]
> ==>v[5]
> ==>v[6]
> ==>v[6]
> ==>[v[1],v[4]]
> ==>[v[4],v[5]]
> ==>[v[3],v[6]]
> ==>[v[2],v[1]]
> ==>[v[1],v[2]]
> ==>[v[1],v[3]]
> {noformat}
> I'm going to create a dev branch and test cases tomorrow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-1979) Several OLAP issues in MathStep
Daniel Kuppitz created TINKERPOP-1979:
-
Summary: Several OLAP issues in MathStep
Key: TINKERPOP-1979
URL: https://issues.apache.org/jira/browse/TINKERPOP-1979
Project: TinkerPop
Issue Type: Bug
Components: process
Reporter: Daniel Kuppitz
{{MathStep}} has a few issues when used in an OLAP query and I think the worst
thing is that both of them are silently ignored by our test suite.
{noformat}
gremlin> g = TinkerFactory.createModern().traversal().withComputer()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
gremlin> g.V().outE().math("0-_").by("weight")
It is not possible to access more than a path element's id on GraphComputer:
MathStep(0-_,[value(weight)]) requires PROPERTIES
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}
This one is just wrong and I'm not sure why {{ComputerVerificationStrategy}}
assumes that the step is trying to leave the star graph. The next one works for
{{TinkerGraphComputer}} but fails in Spark with a serialization-related
exception:
{noformat}
g.V().values("age").math("_")
// leads to the following (ignored) exception:
java.lang.IllegalStateException: org.apache.spark.SparkException: Task not
serializable
at
org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.VertexProgramStep.processNextStart(VertexProgramStep.java:88)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:50)
at
org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.ComputerResultStep.processNextStart(ComputerResultStep.java:68)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
at
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:200)
at
org.apache.tinkerpop.gremlin.process.traversal.Traversal.forEachRemaining(Traversal.java:265)
at
org.apache.tinkerpop.gremlin.process.traversal.step.map.MathTest.serializationTest(MathTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at
org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:53)
at
org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:37)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at
org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:213)
at
org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:51)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.apache.tinkerpop.gremlin.AbstractGremlinSuite$1.evaluate(AbstractGremlinSuite.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
[jira] [Commented] (TINKERPOP-1974) Adding edges during VertexProgram execute with Tinkergraph backend results in ClassCastException
[
https://issues.apache.org/jira/browse/TINKERPOP-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491316#comment-16491316
]
Daniel Kuppitz commented on TINKERPOP-1974:
---
This is by design and you really shouldn't try to mutate edges in an OLAP
graph. I think even your workaround doesn't really do what you think it does.
Since you only have access to the local star-graph, any attempt to create an
edge could only result in an unidirected edge (meaning the vertex on the other
side will not be notified about the new edge).
What you usually want to do is pass a reference to the underlying OLTP graph to
your VertexProgram and then use this graph to create new edges (or remove
existing edges). This works for any provider implementation. However, keep in
mind that OLAP jobs are usually multi-threaded, but TinkerGraph won't support
parallel mutations of the graph; hence you'll have to execute the VertexProgram
using a single worker thread.
If you're not trying to mutate the original graph and the edges were supposed
to be temporary, consider to remodel them as vertex properties.
> Adding edges during VertexProgram execute with Tinkergraph backend results in
> ClassCastException
>
>
> Key: TINKERPOP-1974
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1974
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
>Affects Versions: 3.3.3
>Reporter: Nathaniel Meyer
>Priority: Minor
>
> Attempts to add edges during a vertex program on tinkergraph result in a
> ClassCastException because
> org.apache.tinkerpop.gremlin.process.computer.util.ComputerGraph.ComputerVertex
> can't be cast to class
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.
> In a vertex program designed to add edges to the graph based on rules,
> attempts to call vertex.addEdge(label,otherVertex,edgeProperties) can only
> result in a ClassCastException on Tinkergraph. At runtime, the Vertex
> argument to VertexProgram.execute(vertex,messenger,memory) has class
> org.apache.tinkerpop.gremlin.process.computer.util.ComputerGraph.ComputerVertex.
> Both the vertex and the otherVertex are instances of class
> ComputerGraph.ComputerVertex, but when addEdge is called on the
> ComputerGraph.ComputerVertex instance, internally it calls the addEdge(...)
> of the wrapped TinkerVertex. TinkerVertex.addEdge(...) casts the otherEdge
> to a TinkerVertex, which it is not. There is no way to get an instance of a
> TinkerVertex in a VertexProgram without specifically handling this case,
> casting to ComputerGraph.ComputerVertex or WrappedVertex, and getting the
> wrapped vertex of the other vertex before calling addEdge. This is not
> portable across backends!
> A fix might be to add handling for instances of ComputerGraph.ComputerVertex
> or and get the base vertex before casting to
> TinkerVertex.
> EDIT: Workaround exists, downgrade to minor. Added test for
> WrappedVertex.class in my vertex program and performed a getBaseVertex() call
> on the target vertex before calling addEdge.
> if(WrappedVertex.class.isAssignableFrom(mate.getClass())) {
>
> vertex.addEdge("similarTo",
> ((WrappedVertex)mate).getBaseVertex(), edgeProperties);
> } else {
> vertex.addEdge("similarTo", mate, edgeProperties);
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1973) Emit predicate ignored after final loop of a RepeatStep with times or until
[
https://issues.apache.org/jira/browse/TINKERPOP-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16484214#comment-16484214
]
Daniel Kuppitz commented on TINKERPOP-1973:
---
{quote}the key would be to include the same predicate after the emit{quote}
Right, that's the most common pattern.
{quote}the loop count is no longer available after the traverser has exited the
repeat{quote}
True, but there are several techniques to make it available. The easiest would
be to store the loop counter in the traverser's sack:
{noformat}
g.V()...repeat(...sack(assign).by(loops()))...filter(sack().is(lt(3)))...
{noformat}
If the sack is needed for other things, you can still emit projected values
(containing the actual element and the loop counter).
{noformat}
gremlin>
g.V(1).repeat(optional(select("a")).out().project("a","b").by().by(loops())).emit()
==>[a:v[3],b:0]
==>[a:v[2],b:0]
==>[a:v[4],b:0]
==>[a:v[5],b:1]
==>[a:v[3],b:1]
gremlin>
g.V(1).project("a","b").by().by(constant(-1)).emit().repeat(select("a").out().project("a","b").by().by(loops()))
==>[a:v[1],b:-1]
==>[a:v[3],b:0]
==>[a:v[2],b:0]
==>[a:v[4],b:0]
==>[a:v[5],b:1]
==>[a:v[3],b:1]
{noformat}
> Emit predicate ignored after final loop of a RepeatStep with times or until
> ---
>
> Key: TINKERPOP-1973
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1973
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Ted Wilmes
>Assignee: Ted Wilmes
>Priority: Major
>
> When combined with a {{times}} or {{until}}, the {{emit}} predicate is not
> applied to the output of the last loop of the {{RepeatStep}}.
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
> ==>lop
> ==>lop
> ==>lop
> ==>lop
> gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
> ==>lop
> ==>ripple
> ==>lop
> ==>lop
> ==>lop
> gremlin>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1958) TinkerGraphCountStrategy can return wrong counts
[
https://issues.apache.org/jira/browse/TINKERPOP-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1958.
-
Resolution: Fixed
Fix Version/s: 3.2.10
3.3.4
3.4.0
> TinkerGraphCountStrategy can return wrong counts
>
>
> Key: TINKERPOP-1958
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1958
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.8, 3.3.2
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0, 3.3.4, 3.2.10
>
>
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().map(out())
> ==>v[3]
> ==>v[5]
> ==>v[3]
> gremlin> g.V().map(out()).count()
> ==>6
> gremlin> g.V().select("a")
> gremlin> g.V().select("a").count()
> ==>6
> {noformat}
> Not tested in 3.2.x, but it's probably the same issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1973) Emit predicate ignored after final loop of a RepeatStep with times or until
[
https://issues.apache.org/jira/browse/TINKERPOP-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483090#comment-16483090
]
Daniel Kuppitz commented on TINKERPOP-1973:
---
This is the expected behavior. {{emit()}} is only for intermediate vertices.
You see {{ripple}} because it's the end of the repetition.
{noformat}
gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).path().by('name')
==>[marko,lop]
==>[marko,josh,ripple]
==>[marko,josh,lop]
==>[josh,lop]
==>[peter,lop]
{noformat}
{{emit())) should not be seen as a filter, but rather as an injector.
> Emit predicate ignored after final loop of a RepeatStep with times or until
> ---
>
> Key: TINKERPOP-1973
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1973
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Ted Wilmes
>Assignee: Ted Wilmes
>Priority: Major
>
> When combined with a {{times}} or {{until}}, the {{emit}} predicate is not
> applied to the output of the last loop of the {{RepeatStep}}.
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().repeat(out()).emit(has('name', 'lop')).values('name')
> ==>lop
> ==>lop
> ==>lop
> ==>lop
> gremlin> g.V().repeat(out()).times(2).emit(has('name', 'lop')).values('name')
> ==>lop
> ==>ripple
> ==>lop
> ==>lop
> ==>lop
> gremlin>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1447) Add some JavaScript intelligence to the documentation so that comments and output are not copied in a copy paste
[
https://issues.apache.org/jira/browse/TINKERPOP-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1447.
-
Resolution: Fixed
Fix Version/s: 3.3.4
3.4.0
> Add some JavaScript intelligence to the documentation so that comments and
> output are not copied in a copy paste
>
>
> Key: TINKERPOP-1447
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1447
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0, 3.3.4
>
>
> [~rjbriody] was saying that it is possible to have it such that when you
> copy/paste the following:
> {code}
> gremlin> g.V().out("created") // and example <1>
> ==>blah
> {code}
> only {{g.V().out("created")}} is put into the clipboard. I believe he said it
> was via some JavaScript magic --- beyond me, but it would be cool if we did
> this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (TINKERPOP-1447) Add some JavaScript intelligence to the documentation so that comments and output are not copied in a copy paste
[
https://issues.apache.org/jira/browse/TINKERPOP-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz reassigned TINKERPOP-1447:
-
Assignee: Daniel Kuppitz
> Add some JavaScript intelligence to the documentation so that comments and
> output are not copied in a copy paste
>
>
> Key: TINKERPOP-1447
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1447
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0, 3.3.4
>
>
> [~rjbriody] was saying that it is possible to have it such that when you
> copy/paste the following:
> {code}
> gremlin> g.V().out("created") // and example <1>
> ==>blah
> {code}
> only {{g.V().out("created")}} is put into the clipboard. I believe he said it
> was via some JavaScript magic --- beyond me, but it would be cool if we did
> this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-1960) fold() doesn't fold in OLAP
Daniel Kuppitz created TINKERPOP-1960:
-
Summary: fold() doesn't fold in OLAP
Key: TINKERPOP-1960
URL: https://issues.apache.org/jira/browse/TINKERPOP-1960
Project: TinkerPop
Issue Type: Bug
Affects Versions: 3.2.9
Reporter: Daniel Kuppitz
{noformat}
gremlin> g.withSack(0).V().hasLabel("person").as("from","to").
..1>repeat(both().as("to").dedup("from","to").
..2> sack(sum).by(constant(1))).
..3> emit(hasLabel("person")).
..4>sack().dedup().fold()
==>[1,2,3]
gremlin> g.withComputer().withSack(0).V().hasLabel("person").as("from","to").
..1>repeat(both().as("to").dedup("from","to").
..2> sack(sum).by(constant(1))).
..3> emit(hasLabel("person")).
..4>sack().dedup().fold()
==>[1]
==>[2]
==>[3]
{noformat}
I only noticed the misbehavior in this particular traversal, other tests looked
good, so there must be a step that somehow interferes with {{fold()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-1958) TinkerGraphCountStrategy can return wrong counts
[
https://issues.apache.org/jira/browse/TINKERPOP-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz updated TINKERPOP-1958:
--
Affects Version/s: 3.2.8
> TinkerGraphCountStrategy can return wrong counts
>
>
> Key: TINKERPOP-1958
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1958
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.8, 3.3.2
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().map(out())
> ==>v[3]
> ==>v[5]
> ==>v[3]
> gremlin> g.V().map(out()).count()
> ==>6
> gremlin> g.V().select("a")
> gremlin> g.V().select("a").count()
> ==>6
> {noformat}
> Not tested in 3.2.x, but it's probably the same issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-1958) TinkerGraphCountStrategy can return wrong counts
Daniel Kuppitz created TINKERPOP-1958:
-
Summary: TinkerGraphCountStrategy can return wrong counts
Key: TINKERPOP-1958
URL: https://issues.apache.org/jira/browse/TINKERPOP-1958
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.3.2
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
{noformat}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().map(out())
==>v[3]
==>v[5]
==>v[3]
gremlin> g.V().map(out()).count()
==>6
gremlin> g.V().select("a")
gremlin> g.V().select("a").count()
==>6
{noformat}
Not tested in 3.2.x, but it's probably the same issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1628) Implement TraversalSelectStep
[
https://issues.apache.org/jira/browse/TINKERPOP-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1628.
-
Resolution: Fixed
Fix Version/s: 3.3.3
3.4.0
> Implement TraversalSelectStep
> -
>
> Key: TINKERPOP-1628
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1628
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0, 3.3.3
>
>
> It should be possible to have nested {{select()}} or rather to select dynamic
> keys.
> {noformat}
> gremlin> aliases = ["marko":"okram"]
> gremlin> g.withSideEffect("a", aliases).V().hasLabel("person").
>values("name").as("n").
>optional(select("a").select(select("n")))
> ==>okram
> ==>vadas
> ==>josh
> ==>peter
> {noformat}
> I know there are more steps that could / should allow traversals, but to me
> {{select()}} seems to be the most important one (perhaps because the
> workaround is / can be super expensive).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1948) Sum-step should work on properties of type 'Duration'.
[
https://issues.apache.org/jira/browse/TINKERPOP-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445868#comment-16445868
]
Daniel Kuppitz commented on TINKERPOP-1948:
---
Hmm, in theory, we could allow {{+}} and {{-}} for all {{TemporalAmount}}
values, but this would be much uglier than what I did to support {{min()}} and
{{max()}} for all comparable types. Allowing {{Comparable}} was rather easy
because it's a base interface of {{Number}}, but {{TemporalAmount}} has nothing
in common with {{Number}}, hence {{sum()}} would have to accept arbitrary
{{Object}} s.
I would prefer to have that handled by lambdas:
{noformat}
gremlin> d1 = java.time.Duration.ofDays(1)
==>PT24H
gremlin> d2 = java.time.Duration.ofDays(2)
==>PT48H
gremlin> __.inject(d1, d2).fold(java.time.Duration.ZERO, {a, b -> a + b})
==>PT72H
{noformat}
Maybe we could provide predefined lambdas for some common cases..?
{noformat}
gremlin> __.inject(1, 2).fold(0, sum)
==>3
gremlin> __.inject(d1, d2).fold(java.time.Duration.ZERO, TimeUtil.sum) // this
is made up
==>PT72H
{noformat}
The benefit of this is that predefined lambdas are not treated like custom
lambdas (e.g. in DSE Graph you won't have to allow lambdas to use them).
> Sum-step should work on properties of type 'Duration'.
> --
>
> Key: TINKERPOP-1948
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1948
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.2
>Reporter: Daniel C. Weber
>Priority: Minor
>
> Consider the following query:
> {code:java}
> g.inject(_P1, _P2).sum()
> {code}
> where _P1 and _P2 are bound to values of type 'gx:Duration' (Graphson).
> This will fail with the following error message:
> {code:java}
> [WARN] AbstractEvalOpProcessor - Exception processing a script on request
> [RequestMessage{, requestId=c3e3b3c1-a0dd-4029-b0b6-f7650f6866b3, op='eval',
> processor='', args={gremlin=g.inject(_P1, _P2).sum(), bindings={_P1=PT1S,
> _P2=PT2S}}}].
> java.lang.ClassCastException: java.time.Duration cannot be cast to
> java.lang.Number
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.SumGlobalStep.projectTraverser(SumGlobalStep.java:52)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.SumGlobalStep.projectTraverser(SumGlobalStep.java:37)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ReducingBarrierStep.processAllStarts(ReducingBarrierStep.java:84)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ReducingBarrierStep.processNextStart(ReducingBarrierStep.java:113)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:192)
> at
> org.apache.tinkerpop.gremlin.server.op.AbstractOpProcessor.handleIterator(AbstractOpProcessor.java:89)
> at
> org.apache.tinkerpop.gremlin.server.op.AbstractEvalOpProcessor.lambda$evalOpInternal$5(AbstractEvalOpProcessor.java:252)
> at
> org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.lambda$eval$0(GremlinExecutor.java:274)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> This is obviously due to the fact that the Sum-steps expects its arguments to
> be of type Number, which Duration obviously is not. Since summation of
> Durations is easily available through [this
> method|[https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html#plus-java.time.Duration-]]
> it's worth consideration. The feature would save us an ugly roundtrip by
> saving longs since in some of our queries, we use sum().
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (TINKERPOP-1628) Implement TraversalSelectStep
[
https://issues.apache.org/jira/browse/TINKERPOP-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz reassigned TINKERPOP-1628:
-
Assignee: Daniel Kuppitz
> Implement TraversalSelectStep
> -
>
> Key: TINKERPOP-1628
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1628
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> It should be possible to have nested {{select()}} or rather to select dynamic
> keys.
> {noformat}
> gremlin> aliases = ["marko":"okram"]
> gremlin> g.withSideEffect("a", aliases).V().hasLabel("person").
>values("name").as("n").
>optional(select("a").select(select("n")))
> ==>okram
> ==>vadas
> ==>josh
> ==>peter
> {noformat}
> I know there are more steps that could / should allow traversals, but to me
> {{select()}} seems to be the most important one (perhaps because the
> workaround is / can be super expensive).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1912) Remove MD5 checksums
[ https://issues.apache.org/jira/browse/TINKERPOP-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz closed TINKERPOP-1912. - Resolution: Fixed Fix Version/s: 3.3.3 3.2.9 3.4.0 > Remove MD5 checksums > > > Key: TINKERPOP-1912 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1912 > Project: TinkerPop > Issue Type: Improvement > Components: build-release >Affects Versions: 3.2.7 >Reporter: Daniel Kuppitz >Assignee: Daniel Kuppitz >Priority: Minor > Fix For: 3.4.0, 3.2.9, 3.3.3 > > > Apache is asking to remove MD5 checksums from releases. > *Old policy:* > * MUST provide a MD5-file > * SHOULD provide a SHA-file [SHA-512 recommended] > *New policy:* > * MUST provide a SHA- or MD5-file > * SHOULD provide a SHA-file > * SHOULD NOT provide a MD5-file > Providing MD5 checksum files is now discouraged for new releases, but still > allowed for past releases. > *Why this change:* > * MD5 is broken for many purposes ; we should move away from it. > [https://en.wikipedia.org/wiki/MD5#Overview_of_security_issues] > *Impact for PMCs:* > * _*for new releases:*_ > ** please do provide a SHA-file (one or more, if you like) > ** do NOT provide a MD5-file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1888) Extend max and min to all Comparable properties, not just Numbers
[ https://issues.apache.org/jira/browse/TINKERPOP-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz closed TINKERPOP-1888. - Resolution: Fixed Fix Version/s: 3.4.0 > Extend max and min to all Comparable properties, not just Numbers > - > > Key: TINKERPOP-1888 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1888 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.7 >Reporter: Philip Graff >Assignee: Daniel Kuppitz >Priority: Major > Labels: breaking > Fix For: 3.4.0 > > > Currently, min() and max() only operate on properties that extend Number. > However, these should be able to be applied to anything which implements > Comparable as they are well-defined for those, too. Other steps like mean() > and sum() should stay just for Numbers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1711) map(union(fold())) bug
[
https://issues.apache.org/jira/browse/TINKERPOP-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16424457#comment-16424457
]
Daniel Kuppitz commented on TINKERPOP-1711:
---
Funny, also works in {{tp33/}}, I will mark it as fixed in {{3.3.2}}.
> map(union(fold())) bug
> --
>
> Key: TINKERPOP-1711
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1711
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.5
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.2
>
>
> Actual:
> {code:java}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().valueMap()
> ==>[name:[marko],age:[29]]
> ==>[name:[vadas],age:[27]]
> ==>[name:[lop],lang:[java]]
> ==>[name:[josh],age:[32]]
> ==>[name:[ripple],lang:[java]]
> ==>[name:[peter],age:[35]]
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[[],vadas]
> ==>[lop,[java]]
> ==>[[],josh]
> ==>[ripple,[java]]
> ==>[[],peter]
> {code}
> Expected:
> {code:java}
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[vadas,[]]
> ==>[lop,[java]]
> ==>[josh,[]]
> ==>[ripple,[java]]
> ==>[peter,[]]
> {code}
> List reference:
> https://groups.google.com/forum/#!topic/gremlin-users/L_fESS6ta0A
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1711) map(union(fold())) bug
[
https://issues.apache.org/jira/browse/TINKERPOP-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1711.
-
Resolution: Fixed
Fix Version/s: 3.3.2
> map(union(fold())) bug
> --
>
> Key: TINKERPOP-1711
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1711
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.5
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.2
>
>
> Actual:
> {code:java}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().valueMap()
> ==>[name:[marko],age:[29]]
> ==>[name:[vadas],age:[27]]
> ==>[name:[lop],lang:[java]]
> ==>[name:[josh],age:[32]]
> ==>[name:[ripple],lang:[java]]
> ==>[name:[peter],age:[35]]
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[[],vadas]
> ==>[lop,[java]]
> ==>[[],josh]
> ==>[ripple,[java]]
> ==>[[],peter]
> {code}
> Expected:
> {code:java}
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[vadas,[]]
> ==>[lop,[java]]
> ==>[josh,[]]
> ==>[ripple,[java]]
> ==>[peter,[]]
> {code}
> List reference:
> https://groups.google.com/forum/#!topic/gremlin-users/L_fESS6ta0A
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1711) map(union(fold())) bug
[
https://issues.apache.org/jira/browse/TINKERPOP-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16424448#comment-16424448
]
Daniel Kuppitz commented on TINKERPOP-1711:
---
I don't know why, but in our current {{master/}} the query returns the expected
result:
{noformat}
gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
==>[marko,[]]
==>[vadas,[]]
==>[lop,[java]]
==>[josh,[]]
==>[ripple,[java]]
==>[peter,[]]
{noformat}
> map(union(fold())) bug
> --
>
> Key: TINKERPOP-1711
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1711
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.5
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
>Priority: Major
>
> Actual:
> {code:java}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().valueMap()
> ==>[name:[marko],age:[29]]
> ==>[name:[vadas],age:[27]]
> ==>[name:[lop],lang:[java]]
> ==>[name:[josh],age:[32]]
> ==>[name:[ripple],lang:[java]]
> ==>[name:[peter],age:[35]]
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[[],vadas]
> ==>[lop,[java]]
> ==>[[],josh]
> ==>[ripple,[java]]
> ==>[[],peter]
> {code}
> Expected:
> {code:java}
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[vadas,[]]
> ==>[lop,[java]]
> ==>[josh,[]]
> ==>[ripple,[java]]
> ==>[peter,[]]
> {code}
> List reference:
> https://groups.google.com/forum/#!topic/gremlin-users/L_fESS6ta0A
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-1888) Extend max and min to all Comparable properties, not just Numbers
[ https://issues.apache.org/jira/browse/TINKERPOP-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz updated TINKERPOP-1888: -- Labels: breaking (was: ) > Extend max and min to all Comparable properties, not just Numbers > - > > Key: TINKERPOP-1888 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1888 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.7 >Reporter: Philip Graff >Assignee: Daniel Kuppitz >Priority: Major > Labels: breaking > > Currently, min() and max() only operate on properties that extend Number. > However, these should be able to be applied to anything which implements > Comparable as they are well-defined for those, too. Other steps like mean() > and sum() should stay just for Numbers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1925) Don't apply PathRetractionStrategy recursively
[
https://issues.apache.org/jira/browse/TINKERPOP-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16402032#comment-16402032
]
Daniel Kuppitz commented on TINKERPOP-1925:
---
A quick thought on this: What if {{PathRetractionStrategy}} would just find the
last child traversal and then only kick in when it's applied to this traversal?
Something like this:
{noformat}
apply(traversal) {
// collect all child traversals, starting from the root traversal
if (traversal != last child traversal in list) return;
// apply strategy to root traversal
}
{noformat}
Unfortunately, this child traversal scan has to be done over and over again, as
other strategies could change the result. However, it's just a scan not
involving any mutations, I don't think it would cost too much time.
> Don't apply PathRetractionStrategy recursively
> --
>
> Key: TINKERPOP-1925
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1925
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.7
>Reporter: Daniel Kuppitz
>Priority: Major
>
> {{PathRetractionStrategy}} should not be applied recursively, if possible.
> This is considered an anti-pattern and just recently it caused a lot of
> trouble. This commit fixed the recent issue:
> https://github.com/apache/tinkerpop/commit/b8eb8a02f1675a1b22b86ccc54d22453c65f406f
> {{PathRetractionStrategy}} collects requirements of child traversals, before
> other strategies have a chance to mutate them. When other strategies get to
> the child traversals, mutate them and thus add or remove requirements, a few
> things can go crazy, especially because traverser requirements get cached
> when they're first requested.
> Since I do not fully understand the {{PathRetractionStrategy}} code, my fix
> was actually a workaround. As you can see in the commit linked above, I
> implemented the same anti-pattern in {{SubgraphStrategy}} and
> {{IncidentToAdjacentStrategy}}; these are the 2 strategies that can
> potentially change the traverser requirements.
> It would be nice to revert these changes and instead make
> {{PathRetractionStrategy}} work like all others. However, I'm not sure if
> that's even possible.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
