[
https://issues.apache.org/jira/browse/TINKERPOP-2875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695159#comment-17695159
]
Stephen Mallette commented on TINKERPOP-2875:
---------------------------------------------
I think the behavior is expected. You're not really turning off "bulk
optimizations" by setting that to {{false}}. You're forcing the {{bulk}} for a
{{Traverser}} to "1" basically:
https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/traverser/O_OB_S_SE_SL_Traverser.java#L54-L57
Another example to demonstrate:
{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.E().outV().map{[it,it.bulk()]}
==>[v[1],3]
==>[v[1],3]
==>[v[1],3]
==>[v[4],2]
==>[v[4],2]
==>[v[6],1]
gremlin> g.withBulk(false).E().outV().map{[it,it.bulk()]}
==>[v[1],1]
==>[v[4],1]
==>[v[6],1]
{code}
The documentation is fairly poor on {{withBulk()}} - we can leave this open to
ensure the docs are updated and there are appropriate tests.
> Duplicate elements are omitted when turning off bulk optimization
> -----------------------------------------------------------------
>
> Key: TINKERPOP-2875
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2875
> Project: TinkerPop
> Issue Type: Bug
> Reporter: Lei Tang
> Priority: Major
>
> I create three vertices and two edges.
> {code:java}
> Vertex v1 = g.addV("vl0").property("vp0", 1).next(); // v[1]
> Vertex v2 = g.addV("vl0").property("vp0", 2).next(); // v[2]
> Vertex v3 = g.addV("vl0").property("vp0", 3).next(); // v[3]
> Edge e1 = g.addE("el0").from(v1).to(v2).next();
> Edge e2 = g.addE("el0").from(v1).to(v3).next();{code}
> When I execute the query 'g.E().outV()' without using bulk optimization, I
> expect the result \{v1,v1} is returned. However, it removes the duplicate
> vertices.
> {code:java}
> gremlin> :> g.withBulk(false).E().outV()
> ==>v[1]
> gremlin> :> g.E().outV()
> ==>v[1]
> ==>v[1]
> {code}
> Since I do not use bulk operations in this query, I expect that even if we
> turn off bulk opitmization, we can compute the correct result.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)