[ 
https://issues.apache.org/jira/browse/TINKERPOP-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-1932.
---------------------------------------
    Resolution: Not A Bug

This is not a bug. It is expected behavior. The value returned is deduplicated 
as you say, but the bulk returned is correct:

{code}
gremlin> bytecode = __.inject(1, 1).asAdmin().getBytecode()
==>[[], [inject(1, 1)]]
gremlin> x = client.submit(bytecode).all().get()
==>result{object=1 
class=org.apache.tinkerpop.gremlin.process.remote.traversal.DefaultRemoteTraverser}
gremlin> x.get(0).getObject().bulk()
==>2
{code}

so the value of "1" has a bulk of 2 which means that the client needs to 
"spread" that value of 1 two times. If the client did that then the result 
would be the same as the script. In this way, bytecode can be much faster than 
script based traversals because much less data can be returned over the wire 
for certain result sets. 

If you use an actual remote traversal, you would have seen the client do the 
spreading of the value 1 for you:

{code}
gremlin> graph = EmptyGraph.instance()
==>emptygraph[empty]
gremlin> g = graph.traversal().withRemote(DriverRemoteConnection.using(cluster))
==>graphtraversalsource[emptygraph[empty], standard]
gremlin> g.inject(1,1)
==>1
==>1
{code}

Hope that makes sense.

> Traversal results are implicitly deduplicated when using bytecode
> -----------------------------------------------------------------
>
>                 Key: TINKERPOP-1932
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1932
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: process
>    Affects Versions: 3.3.1
>            Reporter: Dimitry Solovyov
>            Priority: Major
>
> Sending the same query as Gremlin-Groovy and as bytecode yields different 
> results, if the result set contains duplicates. Duplicates are preserved in 
> results from StandardOpProcessor, but dropped in TraversalOpProcessor.
> Deduplication seems to happen when traversers are bulked using a 
> [TraverserSet|https://github.com/apache/tinkerpop/blob/3.3.1/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/traverser/util/TraverserSet.java]
>  in 
> [TraverserIterator|https://github.com/apache/tinkerpop/blob/3.3.1/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/util/TraverserIterator.java].
>  TraverserSet intentionally collects traversers in a hash map. 
> Here is a test that reproduces the issue:
> {code:java}
> Client groovyClient = Cluster.open().connect();
> List<Long> groovyResult = groovyClient.submit("g.inject(1, 
> 1)").stream().map(Result::getLong).collect(toList());
> groovyClient.close();
> Client bytecodeClient = Cluster.open().connect().alias("g");
> Bytecode bytecode = __.inject(1, 1).asAdmin().getBytecode();
> List<Long> bytecodeResult = 
> bytecodeClient.submit(bytecode).stream().map(Result::getLong).collect(toList());
> bytecodeClient.close();
> assertEquals(groovyResult, asList(1L, 1L));
> assertEquals(bytecodeResult, asList(1L, 1L));
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to