[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&utm_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] [Commented] (TINKERPOP-2151) Support for Vertex and Edge property deserialization in Python GLV
[ https://issues.apache.org/jira/browse/TINKERPOP-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16761008#comment-16761008 ] Daniel Kuppitz commented on TINKERPOP-2151: --- We could add {{WithOptions.adjacentIds}} (wouldn't have any effect on vertices, but would add {{outVId}} and {{inVId}} on edges). > Support for Vertex and Edge property deserialization in Python GLV > -- > > Key: TINKERPOP-2151 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2151 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.3.5 >Reporter: Matthew Stafford >Priority: Minor > > It seems that the GraphSON serialization in the Python GLV differs from other > GLVs (I've checked JavaScript and assuming Java as well) in that it doesn't > deserialize Vertex and Edge properties. I've found a few discussions of this > (TINKERPOP-1474, TINKERPOP-1565) but it doesn't seem there was a clear > resolution to whether this was something that'd be addressed in the 3.3.x > series or if things would be left with a lack of parity across GLVs and a > different solution was approached in the 3.4.x series. > As mentioned else where, using `valuesMap` isn't an ideal solution due to the > lack of `inV` and `outV` in the edges. Since this was never quite resolved, > does it make sense for me to go in and make the changes to the GraphSON > serializers? -- 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&focusedCommentId=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], value=[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&focusedCommentId=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&focusedCommentId=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] [Closed] (TINKERPOP-2073) Generate tabs for static code blocks
[ https://issues.apache.org/jira/browse/TINKERPOP-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz closed TINKERPOP-2073. - Resolution: Fixed Fix Version/s: 3.3.5 > 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 > Fix For: 3.3.5 > > > 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] [Assigned] (TINKERPOP-2059) Modulation of valueMap()
[ https://issues.apache.org/jira/browse/TINKERPOP-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz reassigned TINKERPOP-2059: - Assignee: Daniel Kuppitz > 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 > > 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-2073) Generate tabs for static code blocks
[ https://issues.apache.org/jira/browse/TINKERPOP-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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] [Created] (TINKERPOP-2051) Uniqueness of property ids
Daniel Kuppitz created TINKERPOP-2051: - Summary: 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 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-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 > org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.j
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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 com.intellij.junit4.JUnit4I
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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)