date:20180302

[jira] [Commented] (TINKERPOP-1777) Gremlin .max step returns -2147483648 for empty result sets

2018-03-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/805#discussion_r172001752
  
--- Diff: CHANGELOG.asciidoc ---
@@ -25,6 +25,8 @@ NEED AND IMAGE
 
 This release also includes changes from <>.
 
+* Fixed a bug in `ReducingBarrierStep`, that returned the provided seed 
value despite no elements being available.
--- End diff --

Should this be a changelog entry for 3.4.0 as this is pointed at the master 
branch?


> Gremlin .max step returns -2147483648 for empty result sets
> ---
>
> Key: TINKERPOP-1777
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1777
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Sebastian Estevez
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
>
> To reproduce:
> {code}gremlin> g.V().values('test').max()
> ==>-2147483648{code}
> This should probably return an exeption, "cannot take max of nothing"



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

[jira] [Commented] (TINKERPOP-1522) Order of select() scopes

2018-03-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/803
  
As this is has a subtle "breaking" aspect to it, I think you need to write 
up some upgrade docs that explain the change in Gremlin semantics.


> Order of select() scopes
> 
>
> Key: TINKERPOP-1522
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1522
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
>
> As it currently stands, side-effects have the highest priority when a key is 
> {{select()}}'ed. I just ran into a problem where this behavior was more than 
> disadvantageous:
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.withSideEffect("a", ["a": 
> "marko"]).inject(1).select("a").select("a") // expected result is "marko", 
> not "[a:marko]"
> ==>[a:marko]
> {code}
> In my use-case the map keys were not predictable, hence it's almost 
> impossible to prevent a key name collision. IMO maps (and paths) should take 
> precedence over side-effects.
> It is still possible to get the nested {{a}} key, but I'm pretty sure that 
> the common Gremlin user won't be able to come up with this query:
> {code}
> gremlin> g.withSideEffect("a", ["a": "marko"]).inject(1).select("a").
>map(unfold().filter(select(keys).is("a")).select(values))
> ==>marko
> {code}



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

[GitHub] tinkerpop pull request #805: TINKERPOP-1777 Gremlin .max step returns -21474...

2018-03-02 Thread spmallette

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/805#discussion_r172001752
  
--- Diff: CHANGELOG.asciidoc ---
@@ -25,6 +25,8 @@ NEED AND IMAGE
 
 This release also includes changes from <>.
 
+* Fixed a bug in `ReducingBarrierStep`, that returned the provided seed 
value despite no elements being available.
--- End diff --

Should this be a changelog entry for 3.4.0 as this is pointed at the master 
branch?


---

[GitHub] tinkerpop issue #803: TINKERPOP-1522 Order of select() scopes

2018-03-02 Thread spmallette

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/803
  
As this is has a subtle "breaking" aspect to it, I think you need to write 
up some upgrade docs that explain the change in Gremlin semantics.


---

[GitHub] tinkerpop pull request #807: TINKERPOP-1738 Bump to jackson 2.9.4

2018-03-02 Thread spmallette

GitHub user spmallette opened a pull request:

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

TINKERPOP-1738 Bump to jackson 2.9.4

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

This fixes a problem where Jackson was missing an error in GraphSON type 
information depending on the order of the JSON elements. It required some 
internal changes to the GraphSONTypeSerializer given API shifts in jackson - 
should not really affect TinkerPop  users. Modified the original test that 
demonstrated this problem to be a bit more robust.

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

VOTE +1

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

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

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

https://github.com/apache/tinkerpop/pull/807.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 #807


commit f35f04a8da88280e8b121356ac5839fc0b8ac859
Author: Stephen Mallette 
Date:   2018-02-13T15:16:46Z

TINKERPOP-1738 Bump to jackson 2.9.4

This fixes a problem where Jackson was missing an error in GraphSON type 
information depending on the order of the JSON elements. It required some 
internal changes to the GraphSONTypeSerializer given API shifts in jackson - 
should not really affect TinkerPop  users. Modified the original test that 
demonstrated this problem to be a bit more robust.




---

[jira] [Commented] (TINKERPOP-1738) Proper functioning of GraphSONReader depends on order of elements in String representation

2018-03-02 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1738 Bump to jackson 2.9.4

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

This fixes a problem where Jackson was missing an error in GraphSON type 
information depending on the order of the JSON elements. It required some 
internal changes to the GraphSONTypeSerializer given API shifts in jackson - 
should not really affect TinkerPop  users. Modified the original test that 
demonstrated this problem to be a bit more robust.

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

VOTE +1

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

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

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

https://github.com/apache/tinkerpop/pull/807.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 #807


commit f35f04a8da88280e8b121356ac5839fc0b8ac859
Author: Stephen Mallette 
Date:   2018-02-13T15:16:46Z

TINKERPOP-1738 Bump to jackson 2.9.4

This fixes a problem where Jackson was missing an error in GraphSON type 
information depending on the order of the JSON elements. It required some 
internal changes to the GraphSONTypeSerializer given API shifts in jackson - 
should not really affect TinkerPop  users. Modified the original test that 
demonstrated this problem to be a bit more robust.




> Proper functioning of GraphSONReader depends on order of elements in String 
> representation
> --
>
> Key: TINKERPOP-1738
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1738
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: stephen mallette
>Priority: Major
>
> The following two snippets are basically using the same stringified JSON 
> object, it's just the order of elements that is different.
> {noformat}
> gremlin> GraphSONReader.build().create().readObject(new 
> java.io.ByteArrayInputStream('{"@value":{"step":[["addV","poc_int"],["property","bigint1value",{"@value":-4294967295,"@type":"g:Int32"}]]},"@type":"g:Bytecode"}'.getBytes()),
>  Bytecode.class)
> ==>[[], [addV(poc_int), property(bigint1value, 1)]]
> {noformat}
> {noformat}
> gremlin> GraphSONReader.build().create().readObject(new 
> java.io.ByteArrayInputStream('{"@type":"g:Bytecode","@value":{"step":[["addV","poc_int"],["property","bigint1value",{"@type":"g:Int32","@value":-4294967295}]]}}'.getBytes()),
>  Bytecode.class)
> Could not deserialize the JSON value as required. Nested exception: 
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not 
> deserialize the JSON value as required. Nested exception: 
> org.apache.tinkerpop.shaded.jackson.core.JsonParseException: Numeric value 
> (-4294967295) out of range of int
>  at [Source: java.io.ByteArrayInputStream@6d367020; line: 1, column: 126]
>  at [Source: java.io.ByteArrayInputStream@6d367020; line: 1, column: 115] 
> (through reference chain: java.util.ArrayList[1]->java.util.ArrayList[2])
>  at [Source: java.io.ByteArrayInputStream@6d367020; line: 1, column: 115]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}



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

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

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette closed TINKERPOP-1910.
---
Resolution: Duplicate

I think two of these got created by mistake. Discussion is on 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.  
> -
>
> Key: TINKERPOP-1910
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1910
> 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-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.

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette commented on TINKERPOP-1909:
-

There has been much discussion on this topic and as it stands right now the 
general consensus in the community is to not include properties with graph 
elements (vertices/edges/vertexproperties) and we will only return the 
"reference" (i.e. id/label). There are a number of reasons for this, but i 
think that one of the important ones is that users should be encouraged to only 
return the data that they need. I tend to use the example with SQL where you 
would typically not write a query like {{SELECT * FROM table}}}. The same 
applies to graphs. You would write your traversal so as to only return the 
properties that you needed. Returning an entire vertex could open up really big 
performance problems especially with multi-properties. It is better to just not 
allow it.

The general thinking is that a future TinkerPop 4.x will be more tidy in this 
regard (where the JVM side doesn't have properties while other languages do not 
as it is now in TinkerPop 3.x). That's a bit of an unfortunate side of effect 
of our late term development of GLVs (we had no idea that we would be doing 
such a thing for 3.x). I do have some reservation about this model for 4.x 
though, as I would like to improve the transactional model for TinkerPop 4.x 
and I think that client side subgraphs could provide the answer to that - see 
TINKERPOP-1417 for some thoughts on that.

> 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] [Created] (TINKERPOP-1910) Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON.

2018-03-02 Thread Ashwini Singh (JIRA)

Ashwini Singh created TINKERPOP-1910:


 Summary: 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-1910
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1910
 Project: TinkerPop
  Issue Type: Bug
  Components: dotnet
Affects Versions: 3.3.1
Reporter: Ashwini Singh


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] [Created] (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.

2018-03-02 Thread Ashwini Singh (JIRA)

Ashwini Singh created TINKERPOP-1909:


 Summary: 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


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-892) Saving Graph to file won't save graph variables

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette commented on TINKERPOP-892:


Perhaps this was a bad oversight, but our IO formats are pretty well set at 
this point and I can't see us making a change to them for 3.x. I think we leave 
variables up to the graph provider to persist as they see fit. In TinkerPop 4.x 
we can re-think the role of variables and how they might be persisted. I'll 
make a note in the "future dev doc" about this for consideration.

> Saving Graph to file won't save graph variables
> ---
>
> Key: TINKERPOP-892
> URL: https://issues.apache.org/jira/browse/TINKERPOP-892
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: Flavio Cordova
>Priority: Trivial
>
> When you save a graph using writeGraph graph variables are not saved along 
> with all the vertices and edges, so you can't fully recover the graph when 
> you read the file.
> In the forum there's a thread called "Saving graph variables to File" that 
> will discuss the matter in details but basically "I understand the API should 
> handle variables and persist then properly, probably adapting it as a vertex 
> to be compliant to the format, but it should be transparent to the developer, 
> something like neo4J does for multi-properties. IF the way they are written 
> to the file were not good enough [for me] then I could be able to change it 
> writting a custom writer/reader, but not the way around."



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

[jira] [Assigned] (TINKERPOP-659) GraphConfiguration Class

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette reassigned TINKERPOP-659:
--

Assignee: stephen mallette

> GraphConfiguration Class
> 
>
> Key: TINKERPOP-659
> URL: https://issues.apache.org/jira/browse/TINKERPOP-659
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> {{GraphFactory}} currently takes a {{Configuration}} object to construct 
> graph instances.  At first, this was the only TinkerPop use of the 
> {{Configuration}} - the rest was passed on to graph instances for their 
> internal usage.  More recently, the {{Configuration}} can have other 
> important keys like configurations for the {{IoRegistry}}.  The keys for 
> these settings are scattered about gremlin-core (e.g 
> {{gremlin.io.gryo.poolSize}} is in {{GryoPool}}, {{gremlin.graph}} is in 
> {{Graph}}).  
> To better centralize the configuration keys and better support passing around 
> this configuration, a {{GraphConfiguration}} class should be created to be a 
> holder for these configurations.



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

[jira] [Commented] (TINKERPOP-1908) Bump to Groovy 2.4.14

2018-03-02 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1908 Bump to Groovy 2.4.14

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

Bump to Groovy 2.4.14

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-1908

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

https://github.com/apache/tinkerpop/pull/806.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 #806


commit f409564bb1d59b3b9d09e130bf56a0da48c771f3
Author: Stephen Mallette 
Date:   2018-03-02T11:52:09Z

TINKERPOP-1908 Bump to Groovy 2.4.14




> Bump to Groovy 2.4.14
> -
>
> Key: TINKERPOP-1908
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1908
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.8, 3.3.2
>
>
> We were at 2.4.11 prior to this - here's the release notes sets for changes 
> since that version:
> http://groovy-lang.org/changelogs/changelog-2.4.12.html
> http://groovy-lang.org/changelogs/changelog-2.4.13.html
> http://groovy-lang.org/changelogs/changelog-2.4.14.html
> It's mostly bug fixes (with one in 2.4.14 that involves the 
> {{GroovyScriptEngine}} and seems relevantt o our usage)



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

[GitHub] tinkerpop pull request #806: TINKERPOP-1908 Bump to Groovy 2.4.14

2018-03-02 Thread spmallette

GitHub user spmallette opened a pull request:

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

TINKERPOP-1908 Bump to Groovy 2.4.14

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

Bump to Groovy 2.4.14

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-1908

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

https://github.com/apache/tinkerpop/pull/806.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 #806


commit f409564bb1d59b3b9d09e130bf56a0da48c771f3
Author: Stephen Mallette 
Date:   2018-03-02T11:52:09Z

TINKERPOP-1908 Bump to Groovy 2.4.14




---

[jira] [Commented] (TINKERPOP-1777) Gremlin .max step returns -2147483648 for empty result sets

2018-03-02 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user dkuppitz opened a pull request:

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

TINKERPOP-1777 Gremlin .max step returns -2147483648 for empty result sets

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

Fixed the behavior of `min()`, `max()`, `mean()` and `sum()`.
If no input is given, these steps will now throw a `FastNoElementException`.

Also adjusted existing test cases to be in line with the new behavior.

`docker/build.sh -t -i` passed.

VOTE: +1

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

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

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

https://github.com/apache/tinkerpop/pull/805.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 #805


commit 32014426f12478e13d73b3c1bdca8df6d79d08da
Author: Daniel Kuppitz 
Date:   2018-02-27T17:15:07Z

Fixed the behavior of `min()`, `max()`, `mean()` and `sum()`.
If no input is given, these steps will now throw a `FastNoElementException`.

Also adjusted existing test cases to be in line with the new behavior.

commit 7149f8e8c1c255420b19748632ee4d928480f2e2
Author: Daniel Kuppitz 
Date:   2018-03-02T21:04:58Z

Updated release docs




> Gremlin .max step returns -2147483648 for empty result sets
> ---
>
> Key: TINKERPOP-1777
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1777
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Sebastian Estevez
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
>
> To reproduce:
> {code}gremlin> g.V().values('test').max()
> ==>-2147483648{code}
> This should probably return an exeption, "cannot take max of nothing"



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

[GitHub] tinkerpop pull request #805: TINKERPOP-1777 Gremlin .max step returns -21474...

2018-03-02 Thread dkuppitz

GitHub user dkuppitz opened a pull request:

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

TINKERPOP-1777 Gremlin .max step returns -2147483648 for empty result sets

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

Fixed the behavior of `min()`, `max()`, `mean()` and `sum()`.
If no input is given, these steps will now throw a `FastNoElementException`.

Also adjusted existing test cases to be in line with the new behavior.

`docker/build.sh -t -i` passed.

VOTE: +1

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

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

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

https://github.com/apache/tinkerpop/pull/805.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 #805


commit 32014426f12478e13d73b3c1bdca8df6d79d08da
Author: Daniel Kuppitz 
Date:   2018-02-27T17:15:07Z

Fixed the behavior of `min()`, `max()`, `mean()` and `sum()`.
If no input is given, these steps will now throw a `FastNoElementException`.

Also adjusted existing test cases to be in line with the new behavior.

commit 7149f8e8c1c255420b19748632ee4d928480f2e2
Author: Daniel Kuppitz 
Date:   2018-03-02T21:04:58Z

Updated release docs




---

[jira] [Closed] (TINKERPOP-1509) Failing test case for tree serialization

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette closed TINKERPOP-1509.
---
   Resolution: Fixed
Fix Version/s: 3.3.2
   3.2.8

Fixed via CTR on:

https://github.com/apache/tinkerpop/commit/4db099137548d4dcfe2534112282f052710bff9e
 (3.2.8 0 - GraphSON 2.0)

https://github.com/apache/tinkerpop/commit/27cc57469492e9ea6bca8b7db3962fa8e8a9ad4c
 (3.3.2 - GraphSON 3.0)

> Failing test case for tree serialization
> 
>
> Key: TINKERPOP-1509
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1509
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> The failure only seems to happen in some environments. I've ignored the test 
> for now:
> {code}
> org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0Test
> shouldSerializeToTreeJson
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraphGraphSONSerializerV2d0Test.deserializersTestsTree
> {code}



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

[jira] [Updated] (TINKERPOP-1777) Gremlin .max step returns -2147483648 for empty result sets

2018-03-02 Thread Daniel Kuppitz (JIRA)


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

Daniel Kuppitz updated TINKERPOP-1777:
--
Labels: breaking  (was: )

> Gremlin .max step returns -2147483648 for empty result sets
> ---
>
> Key: TINKERPOP-1777
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1777
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Sebastian Estevez
>Priority: Major
>  Labels: breaking
>
> To reproduce:
> {code}gremlin> g.V().values('test').max()
> ==>-2147483648{code}
> This should probably return an exeption, "cannot take max of nothing"



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

[jira] [Assigned] (TINKERPOP-1777) Gremlin .max step returns -2147483648 for empty result sets

2018-03-02 Thread Daniel Kuppitz (JIRA)


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

Daniel Kuppitz reassigned TINKERPOP-1777:
-

Assignee: Daniel Kuppitz

> Gremlin .max step returns -2147483648 for empty result sets
> ---
>
> Key: TINKERPOP-1777
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1777
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Sebastian Estevez
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
>
> To reproduce:
> {code}gremlin> g.V().values('test').max()
> ==>-2147483648{code}
> This should probably return an exeption, "cannot take max of nothing"



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

[jira] [Commented] (TINKERPOP-1509) Failing test case for tree serialization

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette commented on TINKERPOP-1509:
-

The GraphSON 2.0 test for tree now works. GraphSON 3.0 however is failing and 
the tree test in {{GraphSONMessageSerializerV3d0Test}} remains disabled - error 
is:

{code}
[WARN] 
org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0 - 
Response 
[UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf(ridx:
 2240, widx: 2240, cap: 2240)] could not be deserialized by 
org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0.
org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not 
deserialize the JSON value as required. Nested exception: 
org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not 
deserialize the JSON value as required. Nested exception: 
org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not 
deserialize the JSON value as required. Nested exception: 
org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Can not 
deserialize instance of java.lang.Object out of END_ARRAY token
 at [Source: [B@6a28ffa4; line: 1, column: 1119]
 at [Source: [B@6a28ffa4; line: 1, column: 1119] (through reference chain: 
java.util.LinkedHashMap["value"])
 at [Source: [B@6a28ffa4; line: 1, column: 1119] (through reference chain: 
java.util.LinkedHashMap["value"])
 at [Source: [B@6a28ffa4; line: 1, column: 1119] (through reference chain: 
java.util.LinkedHashMap["result"]->java.util.LinkedHashMap["data"])
at 
org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException.from(JsonMappingException.java:270)
at 
org.apache.tinkerpop.shaded.jackson.databind.DeserializationContext.mappingException(DeserializationContext.java:1313)
at 
org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserialize(GraphSONTypeDeserializer.java:194)
at 
org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserializeTypedFromAny(GraphSONTypeDeserializer.java:101)
at 
org.apache.tinkerpop.shaded.jackson.databind.deser.std.UntypedObjectDeserializer.deserializeWithType(UntypedObjectDeserializer.java:290)
at 
org.apache.tinkerpop.shaded.jackson.databind.deser.std.MapDeserializer._readAndBindStringKeyMap(MapDeserializer.java:519)
at 
org.apache.tinkerpop.shaded.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:362)
at 
org.apache.tinkerpop.shaded.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:27)
at 
org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserialize(GraphSONTypeDeserializer.java:219)
at 
org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserializeTypedFromAny(GraphSONTypeDeserializer.java:101)
at 
org.apache.tinkerpop.shaded.jackson.databind.deser.std.UntypedObjectDeserializer.deserializeWithType(UntypedObjectDeserializer.java:290)
at 
org.apache.tinkerpop.shaded.jackson.databind.deser.std.MapDeserializer._readAndBindStringKeyMap(MapDeserializer.java:519)
at 
org.apache.tinkerpop.shaded.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:362)
at 
org.apache.tinkerpop.shaded.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:27)
at 
org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserialize(GraphSONTypeDeserializer.java:212)
at 
org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserializeTypedFromObject(GraphSONTypeDeserializer.java:86)
at 
org.apache.tinkerpop.shaded.jackson.databind.deser.std.MapDeserializer.deserializeWithType(MapDeserializer.java:397)
at 
org.apache.tinkerpop.shaded.jackson.databind.deser.impl.TypeWrappedDeserializer.deserialize(TypeWrappedDeserializer.java:63)
at 
org.apache.tinkerpop.shaded.jackson.databind.DeserializationContext.readValue(DeserializationContext.java:770)
at 
org.apache.tinkerpop.shaded.jackson.databind.DeserializationContext.readValue(DeserializationContext.java:758)
at 
org.apache.tinkerpop.gremlin.structure.io.graphson.AbstractObjectDeserializer.deserialize(AbstractObjectDeserializer.java:48)
at 
org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserialize(GraphSONTypeDeserializer.java:212)
at 
org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserializeTypedFromAny(GraphSONTypeDeserializer.java:101)
at 
org.apache.tinkerpop.shaded.jackson.databind.deser.std.StdDeserializer.deserializeWithType(StdDeserializer.java:120)
at

[jira] [Assigned] (TINKERPOP-1509) Failing test case for tree serialization

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette reassigned TINKERPOP-1509:
---

Assignee: stephen mallette

> Failing test case for tree serialization
> 
>
> Key: TINKERPOP-1509
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1509
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> The failure only seems to happen in some environments. I've ignored the test 
> for now:
> {code}
> org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0Test
> shouldSerializeToTreeJson
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraphGraphSONSerializerV2d0Test.deserializersTestsTree
> {code}



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

Re: Documentation generation with Docker

2018-03-02 Thread Robert Dale

is it possible to share your images and see if it's an image issue or a
docker environment issue?

Robert Dale

On Wed, Feb 28, 2018 at 3:34 PM, Stephen Mallette 
wrote:

> I pushed the fix for master, so I don't have the console problem anymore.
> So now, it's just the issue I guess I've always had.
>
> On Wed, Feb 28, 2018 at 12:18 PM, Robert Dale  wrote:
>
> > That works for me.
> >
> > Robert Dale
> >
> > On Wed, Feb 28, 2018 at 11:23 AM, Florian Hockmann <
> f...@florian-hockmann.de
> > >
> > wrote:
> >
> > > I also ran into the exact same problem in my feature branch for the
> > > docker images which is why haven't added my own vote for the PR yet.
> But
> > > it's good to see that it's really completely unrelated to my changes.
> > >
> > >
> > > Am 28.02.2018 um 17:15 schrieb Stephen Mallette:
> > > > I'm still a bust - same kind of error I keep having -
> > > >
> > > >  * source:   /usr/src/tinkerpop/docs/src/recipes/olap-spark-yarn.
> > > asciidoc
> > > >target:
> > > >  /usr/src/tinkerpop/target/postprocess-asciidoc/recipes/
> > > olap-spark-yarn.asciidoc
> > > >progress:
> > > > [=>
> > > >   ] 65%java.io.IOException: No input paths
> > > > specified in job
> > > > Type ':help' or ':h' for help.
> > > > Display stack trace? [yN]pb(94); ''
> > > >
> > > >
> > > > Last 10 lines of
> > > > /usr/src/tinkerpop/target/postprocess-asciidoc/recipes/
> > > olap-spark-yarn.asciidoc:
> > > >
> > > > gremlin> conf.setProperty('spark.executor.extraLibraryPath',
> > > > "$hadoop/lib/native:$hadoop/lib/native/Linux-amd64-64")
> > > > ==>null
> > > > gremlin> conf.setProperty('gremlin.spark.persistContext', 'true')
> > > > ==>null
> > > > gremlin> graph = GraphFactory.open(conf)
> > > > ==>hadoopgraph[gryoinputformat->gryooutputformat]
> > > > gremlin> g = graph.traversal().withComputer(SparkGraphComputer)
> > > > ==>graphtraversalsource[hadoopgraph[gryoinputformat->
> > gryooutputformat],
> > > > sparkgraphcomputer]
> > > > gremlin> g.V().group().by(values('name')).by(both().count())
> > > > gremlin>
> > > >
> > > > xargs: /usr/src/tinkerpop/docs/preprocessor/preprocess-file.sh:
> exited
> > > with
> > > > status 255; aborting
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Feb 28, 2018 at 10:46 AM, Robert Dale 
> > wrote:
> > > >
> > > >> Yup, it's a step in the release docs.  Once updated, master builds
> > docs
> > > for
> > > >> me.
> > > >>
> > > >> Robert Dale
> > > >>
> > > >> On Wed, Feb 28, 2018 at 10:42 AM, Stephen Mallette <
> > > spmalle...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> ah - i forgot to do that step.i'm running tp32 now to see if
> that
> > > >>> works, but i'll fix that issue on master.
> > > >>>
> > > >>> On Wed, Feb 28, 2018 at 10:41 AM, Robert Dale 
> > > wrote:
> > > >>>
> > >  Could it be that 'bin/gremlin.sh' is linked to a specific version?
> > > Does
> > >  this have to be updated every release?
> > > 
> > >  $ ll gremlin-console/bin/gremlin.sh
> > >  gremlin-console/bin/gremlin.sh ->
> > >  ../target/apache-tinkerpop-gremlin-console-3.3.2-
> > > >>> SNAPSHOT-standalone/bin/
> > >  gremlin.sh
> > > 
> > >  Robert Dale
> > > 
> > >  On Wed, Feb 28, 2018 at 10:37 AM, Robert Dale 
> > > >> wrote:
> > > > I got it too. tp32: good.  tp33: good. master: bad.
> > > >
> > > > Robert Dale
> > > >
> > > > On Wed, Feb 28, 2018 at 10:20 AM, Stephen Mallette <
> > > >>> spmalle...@gmail.com
> > > > wrote:
> > > >
> > > >> I'm having no success generating docs with Docker. On master i'm
> > >  currently
> > > >> getting:
> > > >>
> > > >> Starting namenodes on [localhost]
> > > >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
> > > >> list
> > > >>> of
> > > >> known hosts.
> > > >> localhost: starting namenode, logging to
> > > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-namenode-
> > > >>> 61cfd8f63c77.out
> > > >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
> > > >> list
> > > >>> of
> > > >> known hosts.
> > > >> localhost: starting datanode, logging to
> > > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-datanode-
> > > >>> 61cfd8f63c77.out
> > > >> Starting secondary namenodes [0.0.0.0]
> > > >> 0.0.0.0: Warning: Permanently added '0.0.0.0' (ECDSA) to the
> list
> > > >> of
> > > >> known
> > > >> hosts.
> > > >> 0.0.0.0: starting secondarynamenode, logging to
> > > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-secondarynameno
> > > >> de-61cfd8f63c77.out
> > > >> starting yarn daemons
> > > >> starting resourcemanager, logging to
> > > >> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-resourcemanager-
> > > >> 61cfd8f63c77.out
> > > >> localhost: Warning: Permanently

[jira] [Assigned] (TINKERPOP-1461) StarGraph has bad detach/attach logic for properties.

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette reassigned TINKERPOP-1461:
---

Assignee: (was: stephen mallette)

> StarGraph has bad detach/attach logic for properties.
> -
>
> Key: TINKERPOP-1461
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1461
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop, process, structure
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Priority: Major
>
> The following traversal breaks with a {{NullPointerException}} on 
> {{SparkGraphComputer}}.
> {code}
> g.V().as("a").properties().select("a").outE().properties("skill").as("b").dedup().select("b").by(__.value()));
> {code}
> I believe it has to do with detachment in {{Path}}-data.



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

[jira] [Commented] (TINKERPOP-1461) StarGraph has bad detach/attach logic for properties.

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette commented on TINKERPOP-1461:
-

Just for fun, going on the hint marko left in the previous comment, i made the 
{{Element}} reference non-transient. It fixed the immediate error, but then 
spark got made further down the line in the {{MasterExecutor}} - something 
weird with hashcodes going on maybe as traversers aren't being removed properly 
from the {{toProcessTraversers}} iterator. Anyway, just thought I'd give it a 
try to see if it was a simple fix.

> StarGraph has bad detach/attach logic for properties.
> -
>
> Key: TINKERPOP-1461
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1461
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop, process, structure
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
>
> The following traversal breaks with a {{NullPointerException}} on 
> {{SparkGraphComputer}}.
> {code}
> g.V().as("a").properties().select("a").outE().properties("skill").as("b").dedup().select("b").by(__.value()));
> {code}
> I believe it has to do with detachment in {{Path}}-data.



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

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

2018-03-02 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1862 Messenger proper handling of Direction.BOTH

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

This pulls in all changes from #801 and adds fixes to allow integration 
tests in spark and giraph to pass. 

This isn't completely ready for VOTE yet, but wanted to get it in place for 
review by @PBGraff  to make sure I didn't leave anything out by mistake. Also, 
needed time to for docker tests to run. I will update this PR with a VOTE when 
it's ready for general review.

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

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

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

https://github.com/apache/tinkerpop/pull/804.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 #804


commit f02ea338a8d039c50896f7c65ca57a695975fc43
Author: Graff, Philip B 
Date:   2018-01-04T18:27:44Z

TinkerMessenger proper handling of Direction.BOTH

commit 80c0b8465fe9bb6ddbe4522a36304c7ba054e909
Author: Graff, Philip B 
Date:   2018-01-14T02:32:29Z

Adding simple graph computer test of proper message passing in all 3 
directions

commit 750677cf55d7445c3746870d86c6592f6cd3664d
Author: Graff, Philip B 
Date:   2018-01-14T04:49:27Z

Test cleanup - hopefully can run now

commit 153238b2a8a3fc5e051251662ef6ab80f72c659f
Author: Graff, Philip B 
Date:   2018-01-14T06:01:17Z

Additional check. Tests still fail - but I think this is a problem with the 
implementations, not the test.

commit 5467a33f2e17ad22b736effebede124556f049ed
Author: Graff, Philip B 
Date:   2018-01-14T18:44:33Z

Test bug fix and refactoring repeated code

commit febe0ac8ecdf1828233017864b629a644c7260a8
Author: Graff, Philip B 
Date:   2018-02-25T17:22:39Z

Updating kitchen sink graph

commit f03c4df45473bafcf95d47f34467479f89af73a1
Author: Graff, Philip B 
Date:   2018-02-25T17:35:43Z

Updating message passing tests to use kitchen sink

commit b0b124b84c597079b271adb0dec2044f0c2ec9b3
Author: Graff, Philip B 
Date:   2018-02-25T21:15:40Z

Revert "Updating kitchen sink graph"

This reverts commit febe0ac8ecdf1828233017864b629a644c7260a8.

commit 0490a082d9b533cb7ef4a1a25bd25500844821a6
Author: Graff, Philip B 
Date:   2018-02-25T21:27:28Z

Proper update of kitchen sink through TinkerFactory

commit 027ae2771d3c67bb613c525a689fe10123686b45
Author: Graff, Philip B 
Date:   2018-02-28T16:38:33Z

Using "name" instead of "propertyin"

commit 26a5770efb288d60150cf9db60a5dd67568179f2
Author: Stephen Mallette 
Date:   2018-03-02T16:29:57Z

TINKERPOP-1862 Fix Messenger implementations for Spark/Giraph handling BOTH

These now behave like TinkerMessenger and in the case of BOTH pass the 
message to the opposite vertex in the StarGraph

commit 7956b481b459a9998401abc8b02322f256a73ae7
Author: Stephen Mallette 
Date:   2018-03-02T16:33:21Z

TINKERPOP-1862 Updated changelog




> 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
>

[GitHub] tinkerpop pull request #804: TINKERPOP-1862 Messenger proper handling of Dir...

2018-03-02 Thread spmallette

GitHub user spmallette opened a pull request:

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

TINKERPOP-1862 Messenger proper handling of Direction.BOTH

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

This pulls in all changes from #801 and adds fixes to allow integration 
tests in spark and giraph to pass. 

This isn't completely ready for VOTE yet, but wanted to get it in place for 
review by @PBGraff  to make sure I didn't leave anything out by mistake. Also, 
needed time to for docker tests to run. I will update this PR with a VOTE when 
it's ready for general review.

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

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

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

https://github.com/apache/tinkerpop/pull/804.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 #804


commit f02ea338a8d039c50896f7c65ca57a695975fc43
Author: Graff, Philip B 
Date:   2018-01-04T18:27:44Z

TinkerMessenger proper handling of Direction.BOTH

commit 80c0b8465fe9bb6ddbe4522a36304c7ba054e909
Author: Graff, Philip B 
Date:   2018-01-14T02:32:29Z

Adding simple graph computer test of proper message passing in all 3 
directions

commit 750677cf55d7445c3746870d86c6592f6cd3664d
Author: Graff, Philip B 
Date:   2018-01-14T04:49:27Z

Test cleanup - hopefully can run now

commit 153238b2a8a3fc5e051251662ef6ab80f72c659f
Author: Graff, Philip B 
Date:   2018-01-14T06:01:17Z

Additional check. Tests still fail - but I think this is a problem with the 
implementations, not the test.

commit 5467a33f2e17ad22b736effebede124556f049ed
Author: Graff, Philip B 
Date:   2018-01-14T18:44:33Z

Test bug fix and refactoring repeated code

commit febe0ac8ecdf1828233017864b629a644c7260a8
Author: Graff, Philip B 
Date:   2018-02-25T17:22:39Z

Updating kitchen sink graph

commit f03c4df45473bafcf95d47f34467479f89af73a1
Author: Graff, Philip B 
Date:   2018-02-25T17:35:43Z

Updating message passing tests to use kitchen sink

commit b0b124b84c597079b271adb0dec2044f0c2ec9b3
Author: Graff, Philip B 
Date:   2018-02-25T21:15:40Z

Revert "Updating kitchen sink graph"

This reverts commit febe0ac8ecdf1828233017864b629a644c7260a8.

commit 0490a082d9b533cb7ef4a1a25bd25500844821a6
Author: Graff, Philip B 
Date:   2018-02-25T21:27:28Z

Proper update of kitchen sink through TinkerFactory

commit 027ae2771d3c67bb613c525a689fe10123686b45
Author: Graff, Philip B 
Date:   2018-02-28T16:38:33Z

Using "name" instead of "propertyin"

commit 26a5770efb288d60150cf9db60a5dd67568179f2
Author: Stephen Mallette 
Date:   2018-03-02T16:29:57Z

TINKERPOP-1862 Fix Messenger implementations for Spark/Giraph handling BOTH

These now behave like TinkerMessenger and in the case of BOTH pass the 
message to the opposite vertex in the StarGraph

commit 7956b481b459a9998401abc8b02322f256a73ae7
Author: Stephen Mallette 
Date:   2018-03-02T16:33:21Z

TINKERPOP-1862 Updated changelog




---

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

2018-03-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

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


> 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 pull request #801: TINKERPOP-1862 TinkerMessenger proper handling ...

2018-03-02 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (TINKERPOP-1367) Preserve path history for min() and max()

2018-03-02 Thread Daniel Kuppitz (JIRA)


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

Daniel Kuppitz commented on TINKERPOP-1367:
---

Nah, the workaround is ugly, I really liked the idea of having a 
{{Min/Max/Mean?/Sum?/Count?SideEffectStep}} as shown in this example:

{noformat}
gremlin> g.V().outE().values('weight').max('a').barrier().where(eq('a')).path()
==>[1.0, v[1], e[8][1-knows->4], 1.0]
==>[1.0, v[4], e[10][4-created->5], 1.0]
{noformat}

> Preserve path history for min() and max()
> -
>
> Key: TINKERPOP-1367
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1367
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Jason Plurad
>Priority: Major
>
> Via https://groups.google.com/d/msg/gremlin-users/qZwsvRjw7L4/YyT-s1foBAAJ
> {noformat}
> gremlin> g.V().outE().as('e').values('weight').path()
> ==>[v[1], e[9][1-created->3], 0.4]
> ==>[v[1], e[7][1-knows->2], 0.5]
> ==>[v[1], e[8][1-knows->4], 1.0]
> ==>[v[4], e[10][4-created->5], 1.0]
> ==>[v[4], e[11][4-created->3], 0.4]
> ==>[v[6], e[12][6-created->3], 0.2]
> gremlin> g.V().outE().as('e').values('weight').max().path()
> ==>[1.0]
> {noformat}
> Currently all reducing barriers are treated the same (min, max, mean, etc.). 
> But they are indeed different when it comes to path computations. Some of 
> them could preserve the path history, others could not.
> For max() and min(), we could preserve the path history. In fact, in this 
> respect, max() and min() would NOT be ReducingBarrierSteps, but in fact be 
> some sort of "barrier" FilterStep.



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

[jira] [Assigned] (TINKERPOP-1885) Various Gremlin.Net documentation updates

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette reassigned TINKERPOP-1885:
---

Assignee: Florian Hockmann

> Various Gremlin.Net documentation updates
> -
>
> Key: TINKERPOP-1885
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1885
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation, dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Trivial
> Fix For: 3.2.8, 3.3.2
>
>
> We have some parts of the documentation regarding Gremlin.Net that should be 
> updated now that we have a stable release:
>  * Homepage: _Query Languages_ misses a reference to Gremlin.Net
>  * Homepage: _Language Drivers_ section still links to the repository on my 
> private account. It should probably link to the Gremlin.Net section in the 
> reference docs or to a {{README}} (see below).
>  * Reference docs still contain a warning that _Gremlin.Net does not yet have 
> an official release._
>  * Add a {{README}} that explains Gremlin.Net, similar to the documents we 
> have for the Python and Javascript GLVs.
>  * The {{csproj}} file contains a pretty extensive {{summary}} element, but 
> {{summary}} isn't part of the {{csproj}} standard. So it isn't used for 
> anything. It should be merged into the {{description}} element instead.



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

[jira] [Assigned] (TINKERPOP-1831) Refactor EventStrategy

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette reassigned TINKERPOP-1831:
---

Assignee: stephen mallette

> Refactor EventStrategy 
> ---
>
> Key: TINKERPOP-1831
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1831
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>  Labels: breaking
>
> {{EventStrategy}} has a few issues that could be smoothed out, but not 
> without an allowance for breaking change in the API:
> * For the creation of new properties, an empty detached property is created 
> to represent it - now that detachment is configurable, that doesn't always 
> make sense. For example, if you configured for reference detachment then you 
> would probably want a {{ReferenceProperty}} instead. Not sure how this should 
> be resolved, but it probably needs a change to the eventing API itself
> * Detachment is configured a bit strangely with the use of {{null}} and 
> passing classes for the appropriate detachment factorieswould be nicer to 
> have an interface to represent this stuff.



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

[jira] [Updated] (TINKERPOP-1841) Include Python GLV tests on TravisCI

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette updated TINKERPOP-1841:

Affects Version/s: 3.2.7

> Include Python GLV tests on TravisCI
> 
>
> Key: TINKERPOP-1841
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1841
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.7
>Reporter: Jorge Bay
>Priority: Major
>
> We could avoid the need of manual test runs by using TravisCI to run Python 
> GLV tests.



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

[jira] [Closed] (TINKERPOP-1816) Consider improvements to the .NET documentation

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette closed TINKERPOP-1816.
---
Resolution: Duplicate

Closing as this should resolve as part of TINKERPOP-1805 and TINKERPOP-1447

> Consider improvements to the .NET documentation
> ---
>
> Key: TINKERPOP-1816
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1816
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.6
>Reporter: Bill Woo
>Priority: Minor
>
> Without at least one complete code sample, you are wasting potential users; 
> time.
> How do you run a query/traversal ?  
> By "stumbling around in the dark" I was able to get this far:
> private Graph graph = new Graph();
> private GraphTraversalSource g;
> // in method body
> g = graph.Traversal().WithRemote(new DriverRemoteConnection(new 
> GremlinClient(new GremlinServer("localhost", 8182;
> 
> Vertex v1 = new Vertex("Bill");
> g.AddV(v1);
> Vertex v2 = new Vertex("Julie");
> g.AddV(v2);
> Edge e1 = new Edge("e1", v1, "Knows", v2);
> g.AddE(e1);
> VertexProperty p1 = new VertexProperty("p1","BillProp", 
> "TestProp", v1);



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

[jira] [Assigned] (TINKERPOP-1804) Has step doesn't consider strategy vertexProperty filters

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette reassigned TINKERPOP-1804:
---

Assignee: stephen mallette

> Has step doesn't consider strategy vertexProperty filters
> -
>
> Key: TINKERPOP-1804
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1804
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Simone Cattani
>Assignee: stephen mallette
>Priority: Major
>
> Has step, when used in a traversal defined with strategies, doesn't consider 
> filters applied on properties by the strategies
> Let's consider the crew example adding an old location for Marko, in Seattle, 
> the current Matthias' location.
> {code}
> graph = TinkerFactory.createTheCrew()
> g = graph.traversal()
> g.V().has('name', 'marko').property('location', 'seattle', 'startTime', 1994, 
> 'endTime', 1997)
> {code}
> Defining a strategy that considers just current location I can correctly 
> obtain the list of current locations
> {code}
> g.withStrategies(SubgraphStrategy.build().vertexProperties(or(hasLabel(neq('location')),hasNot('endTime'))).create()).V().hasLabel("person").valueMap()
> ==>[name:[marko],location:[santa fe]]
> ==>[name:[stephen],location:[purcellville]]
> ==>[name:[matthias],location:[seattle]]
> ==>[name:[daniel],location:[aachen]]
> {code}
> But requiring people (currently) living in Seattle, I obtain Marko, too
> {code}
> g.withStrategies(SubgraphStrategy.build().vertexProperties(or(hasLabel(neq('location')),hasNot('endTime'))).create()).V().hasLabel("person").has('location',
>  'seattle').valueMap()
> ==>[name:[marko],location:[santa fe]]
> ==>[name:[matthias],location:[seattle]]
> {code}



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

[jira] [Updated] (TINKERPOP-1774) Gremlin .NET: Support min and max sizes in Connection pool

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette updated TINKERPOP-1774:

Affects Version/s: 3.2.7

> Gremlin .NET: Support min and max sizes in Connection pool
> --
>
> Key: TINKERPOP-1774
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1774
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Jorge Bay
>Priority: Minor
>
> Similar to the java connection pool, we should limit the maximum amount of 
> connections and start with a minimum number.
> It would also a good opportunity to remove the synchronous acquisitions of 
> {{lock}} in the pool implementation.



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

[jira] [Assigned] (TINKERPOP-1685) Introduce optional feature to allow for upserts without read-before-write

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette reassigned TINKERPOP-1685:
---

 Assignee: stephen mallette
Fix Version/s: 3.4.0

I think that this is best implemented with a new {{Graph.Feature}} which will 
leave it up to graph providers to decide how to their insert/update semantics 
work. In this way, we don't have to do anything special to our APIs. 

> Introduce optional feature to allow for upserts without read-before-write
> -
>
> Key: TINKERPOP-1685
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1685
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.4
>Reporter: Jeremy Hanna
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0
>
>
> Currently TINKERPOP-479 is being considered to do some sort of 
> {{getOrCreate}} functionality.  However for some data stores such as 
> Cassandra, this is still short of upserts.  As I understand it, 
> {{getOrCreate}} still has to do a read-before-write.  In cases where the user 
> can guarantee that upserts are going to be idempotent, there is a significant 
> performance improvement and risk avoidance (race condition with 
> multi-threaded read-before-write).  Additionally with some data stores such 
> as Apache Cassandra, the natural way to update data is with an upsert.
> This ticket is to consider adding an additional optional feature to support 
> upserts by default on {{addV}} and {{addE}}.  It could be called something 
> like {{upsert_on_add}}.  This configuration would default to false so that it 
> doesn't break anyone currently relying on errors when adding the same vertex 
> or edge.  However if enabled, it would just add or modify data on the 
> existing vertex or edge.
> If overriding the existing {{addV}} and {{addE}} operations with this 
> optional feature is undesirable, then perhaps new operators could be added 
> like {{upsertV}} and {{upsertE}} or {{putV}} and {{putE}} and those could be 
> used to both add and update the data.  Allowing it to insert data is 
> important because otherwise you are left with having to read-before-write 
> which incurs the performance cost and race condition risk.  A benefit of a 
> separate operator is that you could mix upsert behavior and non-upsert add 
> behavior in a single graph.  I'm not sure there is a huge need to use both in 
> a single graph, but it is a difference between the two strategies.



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

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

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette reopened TINKERPOP-1616:
-

I feel like I was a bit too hasty here.I just came across TINKERPOP-1685 
and I feel like a Graph Feature would be helpful there. Perhaps we should 
address this issue as well. [~pietermartin] were there tests you actually opted 
out of for this issue? or did you just uncover it through other means?

> 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)

[jira] [Commented] (TINKERPOP-1674) Traversals reference elements after deletion

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette commented on TINKERPOP-1674:
-

I was never able to make much headway with this one. The example code was nice, 
but my Scala skills don't make it easy to follow. Is this still an issue given 
the time that has passed? If so, barring some other representation of the 
error, I'm not sure we'll easily get to the bottom of this.

> Traversals reference elements after deletion
> 
>
> Key: TINKERPOP-1674
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1674
> Project: TinkerPop
>  Issue Type: Bug
>  Components: neo4j
>Affects Versions: 3.2.3, 3.2.4
> Environment: Demonstrated on Ubuntu, OSX
>Reporter: SmedbergM
>Priority: Major
>
> In a multiprocessor environment, a traversal will sometimes reference 
> vertices which another thread/processor has already deleted. This causes the 
> entire traversal to fail in an unrecoverable fashion and throw an uncaught 
> exception.
> MWE: https://github.com/SmedbergM/neo4j-deletion-error
> Gist containing logging output: 
> https://gist.github.com/SmedbergM/5fcf0d98a255e7d346b85b98bcc1ec0d
> This error has cropped up persistently over several months/releases (dating 
> back to 3.1.x or earlier). I have not tried to diff back/bisect to find 
> introduction time of the behavior.



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

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

2018-03-02 Thread stephen mallette (JIRA)


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

stephen mallette reassigned TINKERPOP-1616:
---

Assignee: stephen mallette

> 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)

39 matches

Mail list logo