[jira] [Commented] (TINKERPOP-1909) Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON.

[Ashwini Singh (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16384956#comment-16384956
 ] 

Ashwini Singh commented on TINKERPOP-1909:
--

I agree with the direction of gremlin towards being more tidy about data 
communicated between client and server and we should be wary of the performance 
problems with always dealing with multi-properties. But, I still think it would 
be worth consider our ability to de-serialize full vertex/edges if needed.There 
are few options we can consider for future  in TinkerPop 4.x.
 # Using output format, a Gremlin Server configuration. Output format can be 
Ref (return id and label) or GraphSONCompact (Ref+ properties) or 
GraphSON(Ref+properties+ edges). And, Default to Ref. This provides client 
ability to retrieve more details if required and avoid multiple query. And, 
fully controlled by the client.
 # We go ahead with the current ref based object model and let applications 
extend the object model + deserializers if required. Looks doable for 
Gremlin.Net at least.

What do you think ? 

 

> Gremlin.Net does not have complete object model as compared to other client 
> drivers and unable to de-serialize properties for vertex/edge graphSON.  
> -
>
> Key: TINKERPOP-1909
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1909
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.3.1
>Reporter: Ashwini Singh
>Priority: Major
>
> Looks like the object model for Gremlin.Net client driver is not as par with 
> Java driver. We cannot deserialize a GraphSON response to tinkerpop object 
> completely. For example, Gremlin.Net object model cannot deserialize 
> properties from a graphSON response object (vertex/edges). Currently, we only 
> deserialize id and label field from a vertex/edge graphSON.
>  
> So, to desterilize the object model, users have to write a custom 
> deserialization code and create the object. The current de-serializers (for 
> vertex/edge) will strip off details like properties.
>  
> I am filing it as a bug but it could fall into improvement as well.
>  



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

[jira] [Commented] (TINKERPOP-1446) Add a StringFactory for Path which prefixes with type.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16384867#comment-16384867
 ] 

ASF GitHub Bot commented on TINKERPOP-1446:
---

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/810

TINKERPOP-1446 Added standard string representation for Path objects

https://issues.apache.org/jira/browse/TINKERPOP-1446

Only applying this to 3.4.x as people might be relying on the old string 
representations of `Path` objects for some reason. 

All tests pass with `docker/build.sh -t -n -i`

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1446

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/810.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #810


commit c7bf69d98c229dcc5c2f23a17c88d317ae73be6e
Author: Stephen Mallette 
Date:   2018-03-03T17:25:00Z

TINKERPOP-1446 Added standard string representation for Path objects




> Add a StringFactory for Path which prefixes with type.
> --
>
> Key: TINKERPOP-1446
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1446
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Trivial
>
> Here are our various {{StringFactory}} looks:
> {code}
> >>> Vertex(10)
> v[10]
> >>> Edge(2,Vertex(1),"knows",Vertex(2))
> e[2][1-knows->2]
> >>> Property("name","marko")
> p[name->marko]
> >>> VertexProperty(7,"name","marko")
> vp[name->marko]
> >>> Path([],[Vertex(1),"hello",3])
> [v[1], 'hello', 3]
> {code}
> NOTE: this is the same string representation for Gremlin-Java as well.
> Given that {{Path}} is a core interface, I believe it should have a 
> toString() like the other structure interfaces. I propose:
> {code}
> path[v[1], 'hello', 3]
> {code}
> This will make it easy to distinguish it from a list as well.



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

[GitHub] tinkerpop pull request #810: TINKERPOP-1446 Added standard string representa...

[spmallette]

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/810

TINKERPOP-1446 Added standard string representation for Path objects

https://issues.apache.org/jira/browse/TINKERPOP-1446

Only applying this to 3.4.x as people might be relying on the old string 
representations of `Path` objects for some reason. 

All tests pass with `docker/build.sh -t -n -i`

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1446

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/810.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #810


commit c7bf69d98c229dcc5c2f23a17c88d317ae73be6e
Author: Stephen Mallette 
Date:   2018-03-03T17:25:00Z

TINKERPOP-1446 Added standard string representation for Path objects




---

Re: [GitHub] tinkerpop pull request #808: TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final

[Stephen Mallette]

that was dumb should be fixed now

On Sat, Mar 3, 2018 at 10:45 AM, Robert Dale  wrote:

> You need to correct commit message and force push the update.  :-)
>
>
> On Sat, Mar 3, 2018 at 10:33 spmallette  wrote:
>
> > GitHub user spmallette opened a pull request:
> >
> > https://github.com/apache/tinkerpop/pull/808
> >
> > TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final
> >
> > https://issues.apache.org/jira/browse/TINKERPOP-1884
> >
> > Builds with `mvn clean install && mvn verify -pl gremlin-server
> > -DskipIntegrationTests=false`
> >
> > VOTE +1
> >
> > You can merge this pull request into a Git repository by running:
> >
> > $ git pull https://github.com/apache/tinkerpop TINKERPOP-1884
> >
> > Alternatively you can review and apply these changes as the patch at:
> >
> > https://github.com/apache/tinkerpop/pull/808.patch
> >
> > To close this pull request, make a commit to your master/trunk branch
> > with (at least) the following in the commit message:
> >
> > This closes #808
> >
> > 
> > commit 13eab55da267afd0b6fe9c031e5ad0df63c93a3a
> > Author: Stephen Mallette 
> > Date:   2018-03-03T14:41:34Z
> >
> > TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final
> >
> > 
> >
> >
> > ---
> >
> --
> Robert Dale
>

[jira] [Commented] (TINKERPOP-1862) TinkerGraph VertexProgram message passing doesn't work properly when using Direction.BOTH

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16384708#comment-16384708
 ] 

ASF GitHub Bot commented on TINKERPOP-1862:
---

Github user PBGraff commented on the issue:

https://github.com/apache/tinkerpop/pull/804
  
This looks good to me. Thanks for fixing the Spark and Giraph versions as 
well, @spmallette.


> TinkerGraph VertexProgram message passing doesn't work properly when using 
> Direction.BOTH
> -
>
> Key: TINKERPOP-1862
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1862
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process, tinkergraph
>Affects Versions: 3.2.7
>Reporter: Philip Graff
>Priority: Major
>
> I think the messages are being sent properly in TinkerMessenger, but when I 
> call messenger.receiveMessages(), the vertex is getting messages from the 
> outVertex of their edges regardless of the edge direction. This is due to 
> line 71 of TinkerMessenger (linked below) which calls 
> Edge.vertices(direction).next(), thus getting the first result out of the 
> Vertex iterator. For IN or OUT, this isn't a problem. But for BOTH, following 
> line 124 of TinkerEdge (linked below), the outVertex is always returned 
> first. TinkerMessenger needs to be modified to return the correct vertex (I 
> think it's the one that != this.vertex).
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/process/computer/TinkerMessenger.java#L71
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerEdge.java#L124



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

[GitHub] tinkerpop issue #804: TINKERPOP-1862 Messenger proper handling of Direction....

[PBGraff]

Github user PBGraff commented on the issue:

https://github.com/apache/tinkerpop/pull/804
  
This looks good to me. Thanks for fixing the Spark and Giraph versions as 
well, @spmallette.


---

Re: [GitHub] tinkerpop pull request #808: TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final

[Robert Dale]

You need to correct commit message and force push the update.  :-)


On Sat, Mar 3, 2018 at 10:33 spmallette  wrote:

> GitHub user spmallette opened a pull request:
>
> https://github.com/apache/tinkerpop/pull/808
>
> TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final
>
> https://issues.apache.org/jira/browse/TINKERPOP-1884
>
> Builds with `mvn clean install && mvn verify -pl gremlin-server
> -DskipIntegrationTests=false`
>
> VOTE +1
>
> You can merge this pull request into a Git repository by running:
>
> $ git pull https://github.com/apache/tinkerpop TINKERPOP-1884
>
> Alternatively you can review and apply these changes as the patch at:
>
> https://github.com/apache/tinkerpop/pull/808.patch
>
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
>
> This closes #808
>
> 
> commit 13eab55da267afd0b6fe9c031e5ad0df63c93a3a
> Author: Stephen Mallette 
> Date:   2018-03-03T14:41:34Z
>
> TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final
>
> 
>
>
> ---
>
-- 
Robert Dale

[jira] [Commented] (TINKERPOP-1884) Bump to Netty 4.1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16384697#comment-16384697
 ] 

ASF GitHub Bot commented on TINKERPOP-1884:
---

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/809

TINKERPOP-1884 Bump to Netty 4.1.21.Final

https://issues.apache.org/jira/browse/TINKERPOP-1884

I won't bother to submit a separate pull request for master as this should 
merge through just fine.

Builds with mvn clean install && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1884-tp33

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/809.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #809


commit 13eab55da267afd0b6fe9c031e5ad0df63c93a3a
Author: Stephen Mallette 
Date:   2018-03-03T14:41:34Z

TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final

commit 761e681f84cd480db12fc01aff9c9e43e7a742e3
Author: Stephen Mallette 
Date:   2018-03-03T14:43:00Z

Merge branch 'TINKERPOP-1884' into TINKERPOP-1884-tp33

commit 15b252ade2315184f8bfa0df56ad8566813a5426
Author: Stephen Mallette 
Date:   2018-03-03T15:30:48Z

TINKERPOP-1884 Bump to Netty 4.1.21.Final




> Bump to Netty 4.1
> -
>
> Key: TINKERPOP-1884
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1884
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.3.1
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> Netty 4.0.x is EOL:
> https://twitter.com/normanmaurer/status/960798363695435778
> time to bump to 4.1.x



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

[GitHub] tinkerpop pull request #809: TINKERPOP-1884 Bump to Netty 4.1.21.Final

[spmallette]

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/809

TINKERPOP-1884 Bump to Netty 4.1.21.Final

https://issues.apache.org/jira/browse/TINKERPOP-1884

I won't bother to submit a separate pull request for master as this should 
merge through just fine.

Builds with mvn clean install && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1884-tp33

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/809.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #809


commit 13eab55da267afd0b6fe9c031e5ad0df63c93a3a
Author: Stephen Mallette 
Date:   2018-03-03T14:41:34Z

TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final

commit 761e681f84cd480db12fc01aff9c9e43e7a742e3
Author: Stephen Mallette 
Date:   2018-03-03T14:43:00Z

Merge branch 'TINKERPOP-1884' into TINKERPOP-1884-tp33

commit 15b252ade2315184f8bfa0df56ad8566813a5426
Author: Stephen Mallette 
Date:   2018-03-03T15:30:48Z

TINKERPOP-1884 Bump to Netty 4.1.21.Final




---

[jira] [Commented] (TINKERPOP-1884) Bump to Netty 4.1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16384695#comment-16384695
 ] 

ASF GitHub Bot commented on TINKERPOP-1884:
---

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/808

TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final

https://issues.apache.org/jira/browse/TINKERPOP-1884

Builds with `mvn clean install && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false`

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1884

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/808.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #808


commit 13eab55da267afd0b6fe9c031e5ad0df63c93a3a
Author: Stephen Mallette 
Date:   2018-03-03T14:41:34Z

TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final




> Bump to Netty 4.1
> -
>
> Key: TINKERPOP-1884
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1884
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.3.1
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> Netty 4.0.x is EOL:
> https://twitter.com/normanmaurer/status/960798363695435778
> time to bump to 4.1.x



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

[GitHub] tinkerpop pull request #808: TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final

[spmallette]

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/808

TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final

https://issues.apache.org/jira/browse/TINKERPOP-1884

Builds with `mvn clean install && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false`

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1884

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/808.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #808


commit 13eab55da267afd0b6fe9c031e5ad0df63c93a3a
Author: Stephen Mallette 
Date:   2018-03-03T14:41:34Z

TINKERPOP-1884 Bump to TinkerPop 4.0.56.Final




---

[jira] [Updated] (TINKERPOP-1897) Provide Docker images of Gremlin Server and Console

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1897:

Affects Version/s: 3.2.7

> Provide Docker images of Gremlin Server and Console
> ---
>
> Key: TINKERPOP-1897
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1897
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console, server
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> TinkerPop should provide Docker images of Gremlin Server and Gremlin Console 
> that are deployed together with each release.
> This originated from the mailing list:
> [https://lists.apache.org/thread.html/744ae19afa9b2fd1984c1e4dddc588e98786d9c21b633aab8bfa@%3Cdev.tinkerpop.apache.org%3E]



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

[jira] [Updated] (TINKERPOP-1815) Graph io requires the graph API

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1815:

Affects Version/s: 3.2.7

> Graph io requires the graph API
> ---
>
> Key: TINKERPOP-1815
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1815
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.7
>Reporter: Bryn Cooke
>Priority: Major
>
> Currently the io classes use the graph API to populate the graph. For graphs 
> that do not fully support the graph API means that standard IO won't work.
> It would be great if io could use the traversal API for constructing the 
> graph.



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

Re: GremlinPlugin

[Stephen Mallette]

Yeah - whatever you want to make available, you pretty much have to specify
them individually. If i remember right, It helped assure compatibility with
other ScriptEngine instances outside of groovy.

On Sat, Mar 3, 2018 at 6:38 AM, pieter gmail 
wrote:

> Hi,
>
> I am updating Sqlg's gremlin-console support. I have been upgrading Sqlg
> without testing the console and did not realize the changes that has been
> made there.
>
> So I got it to work again but am not quite sure about the ImportCustomizer.
>
> Previously there was no need to individually specify classes to import. Is
> this optional or do every class need to be individually specified? I see
> both TinkerGraph and Neo4 specify some classes but not all.
>
> Thanks
> Pieter
>
>

RE: GremlinPlugin

[pieter gmail]

Hi,

I am updating Sqlg's gremlin-console support. I have been upgrading Sqlg 
without testing the console and did not realize the changes that has 
been made there.


So I got it to work again but am not quite sure about the ImportCustomizer.

Previously there was no need to individually specify classes to import. 
Is this optional or do every class need to be individually specified? I 
see both TinkerGraph and Neo4 specify some classes but not all.


Thanks
Pieter

[jira] [Commented] (TINKERPOP-1616) Strengthen semantics around lazy iteration and graph modifications

[pieter martin (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16384549#comment-16384549
 ] 

pieter martin commented on TINKERPOP-1616:
--

I do have any {{OptOut}} tests for this as such. The test that originally 
highlighted the issue is 
{{EdgeTest.shouldNotHaveAConcurrentModificationExceptionWhenIteratingAndRemovingAddingEdges}}

However the issue remains. TinkerPop is encouraging using inline {{addV}} and 
{{addE}} but as {{gremlin}} does not specify iteration order nor iteration 
depth/laziness a user will never know exactly what the result will be. I do not 
think this can be left to provider documentation. The language needs to be 
exactly specified. The same query can not have different outcomes on different 
providers.

{code:java}
@Test
public void testLazy1AddE() {
final TinkerGraph g = TinkerGraph.open();
final Vertex a1 = g.addVertex(T.label, "A");
final Vertex b1 = g.addVertex(T.label, "B");
final Vertex c1 = g.addVertex(T.label, "C");
a1.addEdge("ab", b1);
a1.addEdge("ac", c1);

GraphTraversal t = g.traversal().V(a1).both().addE("ab").from(a1).to(b1);
List edges = t.toList();
System.out.println(edges.size());
}
{code}

Here is the same example again but this time using inline {{addE}}
For TinkerGraph the result is 2. This is bacause TinkerGraph's implementation 
behaves as though there is a {{barrier}} step before the {{addE}}.

For Sqlg the result is 3. Sqlg is more lazy than TinkerGraph and by the time 
the second {{both}} iteration happens it reads the previously added {{edge}}.

Perhaps the default should be to add in a {{barrier}} step to all modification 
steps?

> Strengthen semantics around lazy iteration and graph modifications
> --
>
> Key: TINKERPOP-1616
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1616
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: pieter martin
>Assignee: stephen mallette
>Priority: Major
>
> The investigation started with the a bothE query where Sqlg returned 
> different results to TinkerGraph
> {code}
> @Test
> public void testLazy1() {
> final TinkerGraph graph = TinkerGraph.open();
> final Vertex a1 = graph.addVertex(T.label, "A");
> final Vertex b1 = graph.addVertex(T.label, "B");
> final Vertex c1 = graph.addVertex(T.label, "C");
> a1.addEdge("ab", b1);
> a1.addEdge("ac", c1);
> AtomicInteger count = new AtomicInteger(0);
> graph.traversal().V(a1).bothE().forEachRemaining(edge -> {
> a1.addEdge("ab", b1);
> c1.addEdge("ac", a1);
> count.getAndIncrement();
> });
> Assert.assertEquals(2, count.get());
> }
> {code}
> For this query TinkerGraph returns 2 and passes.
> Sqlg however returns 3. The reason being that it lazily iterates the out() 
> first and then the in().
> The following gremlin is the same but using a union(out(), in()) instead of 
> bothE()
> {code}
> @Test
> public void testLazy2() {
> final TinkerGraph graph = TinkerGraph.open();
> final Vertex a1 = graph.addVertex(T.label, "A");
> final Vertex b1 = graph.addVertex(T.label, "B");
> final Vertex c1 = graph.addVertex(T.label, "C");
> a1.addEdge("ab", b1);
> a1.addEdge("ac", c1);
> AtomicInteger count = new AtomicInteger(0);
> graph.traversal().V(a1).union(__.outE(), __.inE()).forEachRemaining(edge 
> -> {
> a1.addEdge("ab", b1);
> c1.addEdge("ac", a1);
> count.getAndIncrement();
> });
> Assert.assertEquals(2, count.get());
> }
> {code}
> In this case TinkerGraph returns 4 and Sqlg 6
> TinkerGraph returns 4 as it first walks the 2 out edges and adds 2 in edges 
> which it sees when traversing the in().
> Sqlg return 6 as it lazier than TinkerGraph.
> It first walks the "ac" out edge and adds in the 2 edges.
> Then walks "ab" and gets 2 edges. The original and the one added previously.
> It then walks "ac" in and gets 3 edges as 3 has been added so far.
> All and all 6.
> I am not sure whats the expected semantics. Sqlg is lazier than TinkerGraph 
> but not completely lazy either as it depends more on the meta data and number 
> of queries it needs to execute to walk a particular gremlin query.
> I am somewhat of the opinion that without enforcing a eager iteration when 
> modifying a graph the semantics will be different for different implementors.
> For Sqlg at least it will be hard for clients to predict the behavior.



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