[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=16844377#comment-16844377
]
Daniel Choi commented on TINKERPOP-2220:
True. Ok perhaps dedup not being scoped to each iteration is not a problem, as
you point out you can simulate that by taking (depth, vertex) as the dedup key.
> 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=16844240#comment-16844240
]
Daniel Choi commented on TINKERPOP-2220:
Just realized unrolling doesn't achieve the same outcome as above either; it's
almost like we need a local dedup() per iteration (assuming BFS traversal
order). Perhaps another corroborating point to making a dedicated graph search
step instead of trying to use repeat for this kinds of things.
> 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=16844203#comment-16844203
]
Daniel Choi commented on TINKERPOP-2220:
Yes if you define that's how dedup() should work inside a repeat(), then that
is the correct behavior. And I don't deny it's useful to have it behave this
way. I was just pointing out that it didn't seem to be consistent with how
repeat works in general (repeat the inner traversal verbatim as if unrolled),
but perhaps I'm introducing my own bias here in terms of how repeat should work.
As a counter point, imagine you wanted to do a BFS traversal starting from a
node to all sink nodes, and wanted to print out all distinct nodes at each
frontier depth. In other words, all pairs (d, v), where d=depth and v=vertex.
{code:java}
gremlin>
g.V(1).repeat(identity().as("incoming").project("d","v").by(loops()).by(identity()).aggregate("pairs").select("incoming").out()).cap("pairs")
==>[[d:0,v:v[1]],[d:1,v:v[3]],[d:1,v:v[2]],[d:1,v:v[4]],[d:2,v:v[5]],[d:2,v:v[3]]{code}
Now with dedup:
{code:java}
gremlin>
g.V(1).repeat(identity().as("incoming").project("d","v").by(loops()).by(identity()).aggregate("pairs").select("incoming").out().dedup()).cap("pairs")
==>[[d:0,v:v[1]],[d:1,v:v[3]],[d:1,v:v[2]],[d:1,v:v[4]],[d:2,v:v[5]]]
{code}
Notice how pair *[d:2, v:v[3]]* is gone in the dedup version, even though this
is the first time it's appearing in _depth=2_. You could argue you could
instead do the repeat traversals without any dedup, then later dedup all the
aggregated pairs. But then you're introducing more unnecessary computations at
each depth, for example if ***v[5]* and *v[3]* both had edges going out to
*v[6]*, we'd be processing *v[6]* twice at _depth=3_, only to later dedup the
duplicate pairs created from the double traversal. The problem gets worse as
your traversal tree deepens.**
> 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=16842430#comment-16842430
]
Daniel Choi commented on TINKERPOP-2220:
Thanks Daniel, I see what you're getting at. Although I feel like if dedup()'s
meaning is different in the context of repeat, maybe it would've been better to
separate it out as an explicit argument to do sort of "distinct" graph search
(only process each node once). repeat().distinct(true) or something like that.
It just seems weird that repeat() is normally meant to repeat the inner
traversal verbatim, except if it's a dedup() then it's not (evidenced by
special case handling of dedup() inside repeat() in unroll strategy).
I realize repeat() is usually used to implement graph search like BFS in
gremlin and there are strong merits to having a mechanism to reduce the
frontier based on a visited set, and that dedup() is being used for this use
case. But it seems to start to muddy the semantics of repeat() and maybe it's
better to have repeat() as verbatim repetition of the inner traversal while
making separate dedicated steps for graph search (with various search related
options: bfs, dfs, bi-directional, etc.)?
> 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=16841634#comment-16841634
]
Daniel Choi commented on TINKERPOP-2220:
[~okram] could you chime in on this? The explanation in the 524 pull request
above seems to imply there context carry over is intended between iterations,
but that feels like to me it's breaking the "barrier" nature of dedup(). The
second dedup() is reaching into the first dedup()'s context (the deduping set),
breaking the barrier, so to speak.
> 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=16841634#comment-16841634
]
Daniel Choi edited comment on TINKERPOP-2220 at 5/16/19 6:42 PM:
-
[~okram] could you chime in on this? The explanation in the 524 pull request
above seems to imply context carry over is intended between iterations, but
that feels like to me it's breaking the "barrier" nature of dedup(). The
second dedup() is reaching into the first dedup()'s context (the deduping set),
breaking the barrier, so to speak.
was (Author: dacho00):
[~okram] could you chime in on this? The explanation in the 524 pull request
above seems to imply there context carry over is intended between iterations,
but that feels like to me it's breaking the "barrier" nature of dedup(). The
second dedup() is reaching into the first dedup()'s context (the deduping set),
breaking the barrier, so to speak.
> 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-2170) Compare.eq doesn't produce consistent results
[
https://issues.apache.org/jira/browse/TINKERPOP-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Choi closed TINKERPOP-2170.
--
Resolution: Not A Bug
> 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] [Comment Edited] (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=16778443#comment-16778443
]
Daniel Choi edited comment on TINKERPOP-2170 at 2/26/19 6:37 PM:
-
@[~dkuppitz]
Yes in previous versions (tested on 3.3.2), the comparison of 1.53 float and
double succeeds. Looks like the previous flow used toString -> BigDecimal
comparison flow, and toString was taking care of the "rounding", but each in
its respective number domain. So float was rounded to 1.53 based on
single-precision, instead of being based on double-precision. In reality the
float 1.53 should have been first converted to double, represented precisely as
1.529713897705078125, which is not equal to
1.5300266453525910037569701671600341796875 (value closest to 1.53
in double). And this is exactly what the new code does.
{code:java}
hex bits: Float.toString(d): BigDecimal:
3fc3d707 1.526 1.5261376190185546875
3fc3d708 1.527 1.5273297119140625
3fc3d709 1.529 1.5285218048095703125
3fc3d70a 1.53 1.529713897705078125
3fc3d70b 1.531 1.5309059906005859375
3fc3d70c 1.532 1.53209808349609375
3fc3d70d 1.533 1.5332901763916015625
hex bits: Double.toString(d): BigDecimal:
3ff87ae147ae1478 1.5294
1.5293605115378159098327159881591796875
3ff87ae147ae1479 1.5296
1.5295825561427409411408007144927978515625
3ff87ae147ae147a 1.5298
1.529804600747665972448885440826416015625
3ff87ae147ae147b 1.53
1.5300266453525910037569701671600341796875
3ff87ae147ae147c 1.5302
1.53024868995751603506505489349365234375
3ff87ae147ae147d 1.5305
1.5304707345624410663731396198272705078125
3ff87ae147ae147e 1.5307
1.530692779167366097681224346160888671875
hex bits: Double.toString(d): BigDecimal:
3ff87ae13ffd 1.529713897698
1.529713897698416786852249060757458209991455078125
3ff87ae13ffe 1.5297138977
1.52971389770063723290149937383830547332763671875
3ff87ae13fff 1.529713897703
1.529713897702857678950749686919152736663818359375
3ff87ae14000 1.529713897705 1.529713897705078125
3ff87ae14001 1.529713897707
1.529713897707298571049250313080847263336181640625
3ff87ae14002 1.52971389771
1.52971389770951901709850062616169452667236328125
3ff87ae14003 1.529713897712
1.529713897711739463147750939242541790008544921875
{code}
Ok so it looks like the previous behavior can be classified as a bug and the
new behavior is simply the correct behavior?
was (Author: dacho00):
@[~dkuppitz]
Yes in previous versions (tested on 3.3.2), the comparison of 1.53 float and
double succeeds. Looks like the previous flow used toString -> BigDecimal
comparison flow, and toString was taking care of the "rounding", but each in
its respective number domain. So float was rounded to 1.53 based on
single-precision, instead of being based on double-precision. In reality the
float 1.53 should have been first converted to double, represented precisely as
1.529713897705078125, then rounded to 1.529713897705 in
double-precision which is not equal to
1.5300266453525910037569701671600341796875 (value closest to 1.53
in double).
{code:java}
hex bits: Float.toString(d): BigDecimal:
3fc3d707 1.526 1.5261376190185546875
3fc3d708 1.527 1.5273297119140625
3fc3d709 1.529 1.5285218048095703125
3fc3d70a 1.53 1.529713897705078125
3fc3d70b 1.531 1.5309059906005859375
3fc3d70c 1.532 1.53209808349609375
3fc3d70d 1.533 1.5332901763916015625
hex bits: Double.toString(d): BigDecimal:
3ff87ae147ae1478 1.5294
1.5293605115378159098327159881591796875
3ff87ae147ae1479 1.5296
1.5295825561427409411408007144927978515625
3ff87ae147ae147a 1.5298
1.529804600747665972448885440826416015625
3ff87ae147ae147b 1.53
1.5300266453525910037569701671600341796875
3ff87ae147ae147c
[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=16778443#comment-16778443
]
Daniel Choi commented on TINKERPOP-2170:
@[~dkuppitz]
Yes in previous versions (tested on 3.3.2), the comparison of 1.53 float and
double succeeds. Looks like the previous flow used toString -> BigDecimal
comparison flow, and toString was taking care of the "rounding", but each in
its respective number domain. So float was rounded to 1.53 based on
single-precision, instead of being based on double-precision. In reality the
float 1.53 should have been first converted to double, represented precisely as
1.529713897705078125, then rounded to 1.529713897705 in
double-precision which is not equal to
1.5300266453525910037569701671600341796875 (value closest to 1.53
in double).
{code:java}
hex bits: Float.toString(d): BigDecimal:
3fc3d707 1.526 1.5261376190185546875
3fc3d708 1.527 1.5273297119140625
3fc3d709 1.529 1.5285218048095703125
3fc3d70a 1.53 1.529713897705078125
3fc3d70b 1.531 1.5309059906005859375
3fc3d70c 1.532 1.53209808349609375
3fc3d70d 1.533 1.5332901763916015625
hex bits: Double.toString(d): BigDecimal:
3ff87ae147ae1478 1.5294
1.5293605115378159098327159881591796875
3ff87ae147ae1479 1.5296
1.5295825561427409411408007144927978515625
3ff87ae147ae147a 1.5298
1.529804600747665972448885440826416015625
3ff87ae147ae147b 1.53
1.5300266453525910037569701671600341796875
3ff87ae147ae147c 1.5302
1.53024868995751603506505489349365234375
3ff87ae147ae147d 1.5305
1.5304707345624410663731396198272705078125
3ff87ae147ae147e 1.5307
1.530692779167366097681224346160888671875
hex bits: Double.toString(d): BigDecimal:
3ff87ae13ffd 1.529713897698
1.529713897698416786852249060757458209991455078125
3ff87ae13ffe 1.5297138977
1.52971389770063723290149937383830547332763671875
3ff87ae13fff 1.529713897703
1.529713897702857678950749686919152736663818359375
3ff87ae14000 1.529713897705 1.529713897705078125
3ff87ae14001 1.529713897707
1.529713897707298571049250313080847263336181640625
3ff87ae14002 1.52971389771
1.52971389770951901709850062616169452667236328125
3ff87ae14003 1.529713897712
1.529713897711739463147750939242541790008544921875
{code}
Ok so it looks like the previous behavior can be classified as a bug and the
new behavior is simply the correct behavior?
> 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-2170) Compare.eq doesn't produce consistent results
Daniel Choi created TINKERPOP-2170:
--
Summary: 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
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] [Updated] (TINKERPOP-2042) Bytecode to GLV translation broken for E()
[
https://issues.apache.org/jira/browse/TINKERPOP-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Choi updated TINKERPOP-2042:
---
Description:
_g.E().fold().coalesce(unfold(), g.E())_ is a valid traversal that can be
evaluated if submitted to a gremlin server in String execution mode (i.e., via
console or http). However if the same traversal is submitted as bytecode, the
server throws an error while translating the bytecode back to GLV (perhaps GLV
is not the technically correct term here, I mean when the bytecode is
translated back to gremlin objects in the server's respective language stack).
Stack Trace:
java.lang.IllegalStateException: Could not locate method:
DefaultGraphTraversal.E()
0 = \{StackTraceElement@10575}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:202)"
1 = \{StackTraceElement@10576}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translateObject(JavaTranslator.java:111)"
2 = \{StackTraceElement@10577}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:195)"
3 = \{StackTraceElement@10578}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translate(JavaTranslator.java:87)"
4 = \{StackTraceElement@10579}
"org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:370)"
5 = \{StackTraceElement@10580}
"org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:74)"
6 = \{StackTraceElement@10581}
"org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:49)"
...
This is because E() is not part of GraphTraversal. The commit that introduced
V() into GraphTraversal didn't seem to specify any reasons particularly against
also having E() as part of GraphTraversal:
[https://github.com/apache/tinkerpop/commit/5c5bd06ebbd4ad6781ba46349ebb638f93b4f469].
It'd be a more consistent user experience to also have E() as part of
GraphTraversal so that it can be used mid-traversal similar to V().
Tested on a Java gremlin server, but I suspect this would apply to all other
flavors if GLV spec mandates E() not be part of GraphTraversal.
was:
_g.E().fold().coalesce(unfold(), g.E())_ is a valid traversal that can be
evaluated if submitted to a gremlin server in String execution mode (i.e., via
console or http). However if the same traversal is submitted as bytecode, the
server throws an error while translating the bytecode back to GLV (perhaps GLV
is not the technically correct term here, I mean when the bytecode is
translated back to gremlin objects in the server's respective language stack).
Stack Trace:
0 = \{StackTraceElement@10575}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:202)"
1 = \{StackTraceElement@10576}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translateObject(JavaTranslator.java:111)"
2 = \{StackTraceElement@10577}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:195)"
3 = \{StackTraceElement@10578}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translate(JavaTranslator.java:87)"
4 = \{StackTraceElement@10579}
"org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:370)"
5 = \{StackTraceElement@10580}
"org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:74)"
6 = \{StackTraceElement@10581}
"org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:49)"
...
This is because E() is not part of GraphTraversal. The commit that introduced
V() into GraphTraversal didn't seem to specify any reasons particularly against
also having E() as part of GraphTraversal:
[https://github.com/apache/tinkerpop/commit/5c5bd06ebbd4ad6781ba46349ebb638f93b4f469].
It'd be a more consistent user experience to also have E() as part of
GraphTraversal so that it can be used mid-traversal similar to V().
Tested on a Java gremlin server, but I suspect this would apply to all other
flavors if GLV spec mandates E() not be part of GraphTraversal.
> Bytecode to GLV translation broken for E()
> --
>
> Key: TINKERPOP-2042
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2042
> Project: TinkerPop
> Issue Type: Bug
> Environment: Java GLV
>Reporter: Daniel Choi
>Priority: Major
>
> _g.E().fold().coalesce(unfold(), g.E())_ is a valid traversal that can be
> evaluated if submitted to a gremlin server in String execution mode (i.e.,
> via console or http). However if the same traversal is submitted as
> bytecode, the server throws an error while translating the bytecode back
[jira] [Created] (TINKERPOP-2042) Bytecode to GLV translation broken for E()
Daniel Choi created TINKERPOP-2042:
--
Summary: Bytecode to GLV translation broken for E()
Key: TINKERPOP-2042
URL: https://issues.apache.org/jira/browse/TINKERPOP-2042
Project: TinkerPop
Issue Type: Bug
Environment: Java GLV
Reporter: Daniel Choi
_g.E().fold().coalesce(unfold(), g.E())_ is a valid traversal that can be
evaluated if submitted to a gremlin server in String execution mode (i.e., via
console or http). However if the same traversal is submitted as bytecode, the
server throws an error while translating the bytecode back to GLV (perhaps GLV
is not the technically correct term here, I mean when the bytecode is
translated back to gremlin objects in the server's respective language stack).
Stack Trace:
0 = \{StackTraceElement@10575}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:202)"
1 = \{StackTraceElement@10576}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translateObject(JavaTranslator.java:111)"
2 = \{StackTraceElement@10577}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:195)"
3 = \{StackTraceElement@10578}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translate(JavaTranslator.java:87)"
4 = \{StackTraceElement@10579}
"org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:370)"
5 = \{StackTraceElement@10580}
"org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:74)"
6 = \{StackTraceElement@10581}
"org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:49)"
...
This is because E() is not part of GraphTraversal. The commit that introduced
V() into GraphTraversal didn't seem to specify any reasons particularly against
also having E() as part of GraphTraversal:
[https://github.com/apache/tinkerpop/commit/5c5bd06ebbd4ad6781ba46349ebb638f93b4f469].
It'd be a more consistent user experience to also have E() as part of
GraphTraversal so that it can be used mid-traversal similar to V().
Tested on a Java gremlin server, but I suspect this would apply to all other
flavors if GLV spec mandates E() not be part of GraphTraversal.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
