[jira] [Commented] (TINKERPOP-1572) Impossible to get DetachedVertex when Connecting via withRemote

[Robert Dale (JIRA)]

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

Robert Dale commented on TINKERPOP-1572:


I set the affects version to 3.2.0-incubating because it's true there although 
`is.testing` doesn't seem to affect it.

> Impossible to get DetachedVertex when Connecting via withRemote 
> 
>
> Key: TINKERPOP-1572
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1572
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.2.0-incubating
>Reporter: Robert Dale
>Assignee: stephen mallette
>
> Problem:
> Using gremlin-console:
> {noformat}
> gremlin> graph = EmptyGraph.instance()
> ==>emptygraph[empty]
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[emptygraph[empty], standard]
> gremlin> g.addV('foo').property('key','value')
> ==>v[0]
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
> {noformat}
> Works when is.testing=true
> {noformat}
> export JAVA_OPTIONS="-Dis.testing=true"
> # restart server
> # repeat above test, result is:
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex
> {noformat}
> Appears to be a condition in 
> org.apache.tinkerpop.gremlin.server.util.TraverserIterator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TINKERPOP-1572) Impossible to get DetachedVertex when Connecting via withRemote

[Robert Dale (JIRA)]

Robert Dale created TINKERPOP-1572:
--

 Summary: Impossible to get DetachedVertex when Connecting via 
withRemote 
 Key: TINKERPOP-1572
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1572
 Project: TinkerPop
  Issue Type: Bug
  Components: server
Affects Versions: 3.2.0-incubating
Reporter: Robert Dale
Assignee: stephen mallette


Problem:
Using gremlin-console:
{noformat}
gremlin> graph = EmptyGraph.instance()
==>emptygraph[empty]
gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
==>graphtraversalsource[emptygraph[empty], standard]
gremlin> g.addV('foo').property('key','value')
==>v[0]
gremlin> g.V().next().getClass()
==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
{noformat}


Works when is.testing=true
{noformat}
export JAVA_OPTIONS="-Dis.testing=true"
# restart server
# repeat above test, result is:
gremlin> g.V().next().getClass()
==>class org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex
{noformat}

Appears to be a condition in 
org.apache.tinkerpop.gremlin.server.util.TraverserIterator





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[Kevin Gallardo (JIRA)]

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

Kevin Gallardo commented on TINKERPOP-1565:
---

Fair enough, if the maintenance issue is deemed not important enough, just 
trying to make sure we don't make mistake if we go back to that code months 
later and all that is not fresh in our heads anymore. I understand the argument 
of the size efficiency/repeated data (even though I already said it was not 
part of the goals of GraphSON2 otherwise GraphSON2 wouldn't look like that), 
but it still bothers me though to represent the Same thing, in 2 different ways 
(on one side VertexProperties as part of a Vertex, the other as a standalone 
object).
Also to expand on the point "3." I mentioned earlier I hoped that the work made 
on GraphSON2 would allow to get a JSON representation closer to the actual 
objects as what is serialized in the Gryo protocol so that we could establish 
some sort of general spec for TinkerPop serialization that would be generic 
enough to apply to all the TinkerPop serialization protocols and also 
facilitate the addition of new ones, BUT I'm maybe overreaching there...

> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and 
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official 
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to 
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded 
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded 
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex 
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new 
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired, 
> we only send/recv information that is needed for the particular 
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[Kevin Gallardo (JIRA)]

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

Kevin Gallardo commented on TINKERPOP-1565:
---

When you say "supports both DetachXXX and ReferenceXXX", you mean when 
serializing?

> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and 
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official 
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to 
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded 
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded 
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex 
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new 
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired, 
> we only send/recv information that is needed for the particular 
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TINKERPOP-1571) Be able to drop side-effects, paths, and entries with drop().

[Marko A. Rodriguez (JIRA)]

Marko A. Rodriguez created TINKERPOP-1571:
-

 Summary: Be able to drop side-effects, paths, and entries with 
drop().
 Key: TINKERPOP-1571
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1571
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.3
Reporter: Marko A. Rodriguez


It would be nice to be able to do the following:

{code}
g.V().out().aggregate('x').in().where(without('x')).barrier().drop('x')...
{code}

{code}
g.V().as('a').out().as('b').drop('b')...
{code}

{code}
g.V().project('a','b','c').by(..).by(..).by(..).order().by('c').drop('c')...
{code}


The first two allow the user to hardcode optimizations, but the latter, is more 
of a data formatting usage. Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1565:
---

There are only 4 things to consider -- Vertex, Edge, VertexProperty, and 
Property. Thus, maintainability of the de/serializers isn't that big of a deal. 
Next, because there are only 4 things to consider, the code to treat each type 
individually without cascade is trivial (a morning efforts tweak to what we 
have now).

So regarding JSON size ---

{{g:Property}} will have to have reference to its parents (element+vertex ids) 
to get attached. Thus, "cascading" introduces lots of repeated data. And when 
you start adding {{@type}} to ids and stuff, this gets big. For instance, if we 
use "cascading," then when you serialize a vertex, you have:

{code}
Vertex -> VertexProperties (with ref id back to vertex and label) -> Properties 
(with ref it back to vertex property and back to vertex and key)
{code}

If we treat {{Vertex}} independent of the serialization of {{VertexProperty}} 
and {{Property}} we won't incur repeated data and lots of {{@type}} object 
nesting.

{code}
Vertex -> label:[VertexProperties (just id/value/properties)]  -> 
key:[Properties (just value)]
{code}

Finally with {{getOrCreate()}} optional fields, we don't have to have 
{{VertexProperty.properties()}} field if it doesn't exist. If the vertex is 
just a {{ReferenceVertex}}, all it has is id. etc. etc... 




> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and 
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official 
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to 
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded 
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded 
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex 
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new 
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired, 
> we only send/recv information that is needed for the particular 
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
I would ignore sub-packages right now. Again, lets start off small, get 
things passing, and over time, add more packages to check.


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
I would ignore sub-packages right now. Again, lets start off small, get 
things passing, and over time, add more packages to check.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[metlos]

Github user metlos commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
>  org.apache.tinkerpop.gremlin.structure
>  org.apache.tinkerpop.gremlin.structure.io
>  org.apache.tinkerpop.gremlin.process.computer
>  org.apache.tinkerpop.gremlin.process.traversal
>  org.apache.tinkerpop.gremlin.process.traversal.dsl.graph

Is this the full list of packages or should the sub-packages of these be 
included, too?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
I'm on Apache Maven 3.3.9 (latest). So I'm ok with downgrading :trollface:


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[robertdale]

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
I'm on Apache Maven 3.3.9 (latest). So I'm ok with downgrading :trollface:


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
i'm still on 3.0.5 - i guess i don't mind upgrading, but we should see what 
others think (if anything). Do we even want to force an upgrade for TinkerPop 
3.2.x? maybe this should go to master for 3.3.0? i guess i'll wait a day for 
any comments here and then start a thread on dev to assure consensus.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
i'm still on 3.0.5 - i guess i don't mind upgrading, but we should see what 
others think (if anything). Do we even want to force an upgrade for TinkerPop 
3.2.x? maybe this should go to master for 3.3.0? i guess i'll wait a day for 
any comments here and then start a thread on dev to assure consensus.


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[Kevin Gallardo (JIRA)]

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

Kevin Gallardo edited comment on TINKERPOP-1565 at 11/28/16 9:30 PM:
-

"I think we should treat each element type individually"

So that's another option, as long as all do the same consistently, but why 
would we do that? Is it only for the size of the payload? The way I see it I 
find it useful to rely on that "cascade" because: 1. we have to rely on it 
anyway for the other "non Graph structural" types - 2. it simplifies the 
deserialization logic - 3. it reflects directly what the actual objects are in 
the actual implementation of the serialized objects - 4. it may cause 
inconsistencies otherwise, considering one would change one day the code of the 
VertexPropertyDeserializer, but do not in the VertexDeserializer, and would 
need to do it there as well, so all in all, it's a code maintenance 
inconvenience. 

The docs say that StarGraph serialization is a format made for size efficiency, 
which we had said was not to be a concern with the GraphSON2 standard 
serialization. If that's not the case then fine but there is then a lot of over 
things we can do to make the GraphSON2 protocol more size efficient, but that 
was clearly not stated as a goal initially. For example types names are encoded 
with a descriptive name as well as the "@type" and "@value" identifiers, where 
all could be smaller but it was decided that we wanted to be more descriptive 
here, as other future protocols can be made and be much more size efficient.


was (Author: newkek):
"I think we should treat each element type individually"

So that's another option, as long as all do the same consistently, but why 
would we do that? Is it only for the size of the payload? The way I see it I 
find it useful to rely on that "cascade" because: 1. we have to rely on it 
anyway for the other "non Graph structural" types - 2. it simplifies the 
deserialization logic - 3. it reflects directly what the actual objects are in 
the actual implementation of the serialized objects - 4. it may cause 
inconsistencies otherwise, considering one would change one day the code of the 
VertexPropertyDeserializer, but do not in the VertexDeserializer, and would 
need to do it there as well, so all in all, it's a code maintenance 
inconvenience. 

The docs say that StarGraph is a format made for size efficiency, which we had 
said was not to be a concern with the GraphSON2 standard serialization. If 
that's not the case then fine but there is then a lot of over things we can do 
to make the GraphSON2 protocol more size efficient, but that was clearly not 
stated as a goal initially. For example types names are encoded with a 
descriptive name as well as the "@type" and "@value" identifiers, where all 
could be smaller but it was decided that we wanted to be more descriptive here, 
as other future protocols can be made and be much more size efficient.

> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and 
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official 
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to 
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded 
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded 
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex 
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both 

[jira] [Commented] (TINKERPOP-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user metlos commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
`.travis.install-maven.sh` is a workaround I used in another project for 
https://github.com/travis-ci/travis-ci/issues/4872. Trusty, which is the distro 
used on Travis for Tinkerpop builds, provides Maven 3.1.1, which is too old for 
Revapi which needs at least 3.2.5.

I will push another commit with the changes necessary to track the ignored 
(aka intentional) API changes. It will be similar to 
http://revapi.org/modules/revapi-maven-plugin/examples/multi-file-configuration.html.


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[metlos]

Github user metlos commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
`.travis.install-maven.sh` is a workaround I used in another project for 
https://github.com/travis-ci/travis-ci/issues/4872. Trusty, which is the distro 
used on Travis for Tinkerpop builds, provides Maven 3.1.1, which is too old for 
Revapi which needs at least 3.2.5.

I will push another commit with the changes necessary to track the ignored 
(aka intentional) API changes. It will be similar to 
http://revapi.org/modules/revapi-maven-plugin/examples/multi-file-configuration.html.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[Kevin Gallardo (JIRA)]

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

Kevin Gallardo commented on TINKERPOP-1565:
---

"I think we should treat each element type individually"

So that's another option, as long as all do the same consistently, but why 
would we do that? Is it only for the size of the payload? The way I see it I 
find it useful to rely on that "cascade" because: 1. we have to rely on it 
anyway for the other "non Graph structural" types - 2. it simplifies the 
deserialization logic - 3. it reflects directly what the actual objects are in 
the actual implementation of the serialized objects - 4. it may cause 
inconsistencies otherwise, considering one would change one day the code of the 
VertexPropertyDeserializer, but do not in the VertexDeserializer, and would 
need to do it there as well, so all in all, it's a code maintenance 
inconvenience. 

The docs say that StarGraph is a format made for size efficiency, which we had 
said was not to be a concern with the GraphSON2 standard serialization. If 
that's not the case then fine but there is then a lot of over things we can do 
to make the GraphSON2 protocol more size efficient, but that was clearly not 
stated as a goal initially. For example types names are encoded with a 
descriptive name as well as the "@type" and "@value" identifiers, where all 
could be smaller but it was decided that we wanted to be more descriptive here, 
as other future protocols can be made and be much more size efficient.

> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and 
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official 
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to 
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded 
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded 
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex 
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new 
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired, 
> we only send/recv information that is needed for the particular 
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TINKERPOP-1539) Create a ComplexTraversalTest with crazy nested gnarly traversals.

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez updated TINKERPOP-1539:
--
Assignee: Daniel Kuppitz

> Create a ComplexTraversalTest with crazy nested gnarly traversals.
> --
>
> Key: TINKERPOP-1539
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1539
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process, test-suite
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>
> Our {{ProcessSuite}} has numerous tests verifying the semantics of the 
> various steps. Unfortunately, these tests are on simple traversals focused on 
> exposing the step in question in isolation.
> It would be good to add {{ComplexTraversalTest}} to the {{ProcessSuite}} 
> which has traversals over the Grateful Dead graph (for complexity reasons) 
> doing:
> 1. Numerous nests.
> 2. Match/Select/Where complexities.
> 3. Global side-effect access and unrolling and injecting.
> 4. ... just a bunch of nasty stuff.
> This will give us much more confidence as we add more strategies and 
> potentially, mess up our algebra which isn't exposed by the simple 
> "flat'-traversals we current test with.
> [~dkuppitz] --- would you be interested in doing this?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1567) GraphSON deserialization fails with within('a')

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1567:
---

{code}
>>> g.withSideEffect('a',['josh','peter']).V(1).out('created').in_('created').values('name').where(P.within('a')).toList()
[u'josh', u'peter']
>>> g.withSideEffect('a',['josh','peter']).V(1).out('created').in_('created').values('name').where(within('a')).toList()
[u'josh', u'peter']
{code}

> GraphSON deserialization fails with within('a')
> ---
>
> Key: TINKERPOP-1567
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1567
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant, server
>Affects Versions: 3.2.3
> Environment: Demonstrated on Ubuntu 14.04 and Debian Testing
>Reporter: Branden Moore
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.4
>
>
> Using the gremlin-python interface, when I attempt to run an example from the 
> Documentation of {{where}}:
> {code}
> g.withSideEffect('a','josh','peter']).V(1).out('created').in_('created').values('name').where(P.within('a')).toList()
> {code}
> The server returns a deserialization error:
> {noformat}
> {{[WARN] OpExecutorHandler - Could not deserialize the JSON value as 
> required. Nested exception: 
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingExce[18/147]
> ould not deserialize the JSON value as required. Nested exception: 
> java.lang.IllegalStateException: 
> org.apache.tinkerpop.gremlin.process.traversal.P.within(java.la
> ng.Object)
> 
>  at [Source: 
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in
> ","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
>  line: 1, column: 248] (through reference chain: java.util.
> LinkedHashMap["step"]->java.util.ArrayList[4]->java.util.ArrayList[1])
>  
>  at [Source: 
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in
> ","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
>  line: 1, column: 248]
> 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: java.lang.IllegalStateException: 
> org.apache.tinkerpop.gr
> emlin.process.traversal.P.within(java.lang.Object)
>   
> at [Source: 
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in
> ","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
>  line: 1, column: 248] (through reference chain: 
> java.util.LinkedHashMap["step"]->java.util.ArrayList[4]->java.util.ArrayList[1])
>  at [Source: 
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
>  line: 1, column: 248] 
> at 
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException.from(JsonMappingException.java:216)
>at 
> org.apache.tinkerpop.shaded.jackson.databind.DeserializationContext.mappingException(DeserializationContext.java:883)
>at 
> org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserialize(GraphSONTypeDeserializer.java:195)
> at 
> org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTypeDeserializer.deserializeTypedFromAny(GraphSONTypeDeserializer.java:102)
> at 
> org.apache.tinkerpop.shaded.jackson.databind.deser.std.StdDeserializer.deserializeWithType(StdDeserializer.java:120)
> at 
> org.apache.tinkerpop.shaded.jackson.databind.deser.impl.TypeWrappedDeserializer.deserialize(TypeWrappedDeserializer.java:42)
> at 
> org.apache.tinkerpop.shaded.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3789)
> at 
> org.apache.tinkerpop.shaded.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2779)
> at 
> 

[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/446#discussion_r89875249
  
--- Diff: 
gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/ValueMapTest.java
 ---
@@ -125,6 +131,30 @@ public void g_VX1X_outXcreatedX_valueMap() {
 
 }
 
+/**
+ * TINKERPOP-1483
+ * 
+ */
+@Test
+@LoadGraphWith(MODERN)
+public void valueMapHasObjectKeys() {
--- End diff --

This method is named wrong, it should be like the traversal generator 
method name, minus the `get_` prefix.


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop pull request #446: TINKERPOP-1483: valueMap should always return s...

[okram]

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

https://github.com/apache/tinkerpop/pull/446#discussion_r89875249
  
--- Diff: 
gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/ValueMapTest.java
 ---
@@ -125,6 +131,30 @@ public void g_VX1X_outXcreatedX_valueMap() {
 
 }
 
+/**
+ * TINKERPOP-1483
+ * 
+ */
+@Test
+@LoadGraphWith(MODERN)
+public void valueMapHasObjectKeys() {
--- End diff --

This method is named wrong, it should be like the traversal generator 
method name, minus the `get_` prefix.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/446#discussion_r89875173
  
--- Diff: 
gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/map/GroovyValueMapTest.groovy
 ---
@@ -42,5 +42,10 @@ public abstract class GroovyValueMapTest {
 public Traversal> 
get_g_VX1X_outXcreatedX_valueMap(final Object v1Id) {
 new ScriptTraversal<>(g, "gremlin-groovy", 
"g.V(v1Id).out('created').valueMap", "v1Id", v1Id)
 }
+
+@Override
+public Traversal> 
get_g_V_valueMapToken() {
--- End diff --

This method is named wrong, it should be:

```
get_g_V_hasLabelXpersonX_filterXoutEXcreatedXX_valueMapXtrueX()
```


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop pull request #446: TINKERPOP-1483: valueMap should always return s...

[okram]

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

https://github.com/apache/tinkerpop/pull/446#discussion_r89875173
  
--- Diff: 
gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/map/GroovyValueMapTest.groovy
 ---
@@ -42,5 +42,10 @@ public abstract class GroovyValueMapTest {
 public Traversal> 
get_g_VX1X_outXcreatedX_valueMap(final Object v1Id) {
 new ScriptTraversal<>(g, "gremlin-groovy", 
"g.V(v1Id).out('created').valueMap", "v1Id", v1Id)
 }
+
+@Override
+public Traversal> 
get_g_V_valueMapToken() {
--- End diff --

This method is named wrong, it should be:

```
get_g_V_hasLabelXpersonX_filterXoutEXcreatedXX_valueMapXtrueX()
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (TINKERPOP-1570) Bump to Netty 4.0.42

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1570:
---

 Summary: Bump to Netty 4.0.42
 Key: TINKERPOP-1570
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1570
 Project: TinkerPop
  Issue Type: Improvement
  Components: driver, server
Affects Versions: 3.2.3
Reporter: stephen mallette
Assignee: stephen mallette
Priority: Minor
 Fix For: 3.2.4


Mostly a bunch of bug fixes have come in the latest two versions of Netty - not 
sure there is anything specific to TinkerPop that is currently known as a 
problem, but it's probably good to keep up with these patch releases:

http://netty.io/news/2016/08/29/4-0-41-Final-4-1-5-Final.html
http://netty.io/news/2016/10/14/4-0-42-Final-4-1-6-Final.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1565:
-

well - we did have "beta" in mind, but we have the capability to version our 
formats. maybe not a big deal to stamp out GraphSON 2.1 as part of 3.3.x. 

> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and 
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official 
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to 
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded 
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded 
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex 
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new 
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired, 
> we only send/recv information that is needed for the particular 
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #446: TINKERPOP-1483: valueMap should always return string k...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
I just realized that `valueMap()` is `Map`, but 
`valueMap(boolean)` is `Map`. We should maintain that level of 
explicitness as I suspect in the future `valueMap(boolean)` will change given 
that its sort of a wart right now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
I just realized that `valueMap()` is `Map`, but 
`valueMap(boolean)` is `Map`. We should maintain that level of 
explicitness as I suspect in the future `valueMap(boolean)` will change given 
that its sort of a wart right now.


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/446#discussion_r89863961
  
--- Diff: CHANGELOG.asciidoc ---
@@ -46,6 +46,7 @@ TinkerPop 3.3.0 (Release Date: NOT OFFICIALLY RELEASED 
YET)
 * Removed `tryRandomCommit()` from `AbstractGremlinTest`.
 * Changed `gremlin-benchmark` system property for the report location to 
`benchmarkReportDir` for consistency.
 * Added SysV and systemd init scripts.
+* `valueMap` now returns a `Map` since keys could be `T.id` or 
`T.label`.
--- End diff --

Please make it read `GraphTraversal.valueMap()`.


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop pull request #446: TINKERPOP-1483: valueMap should always return s...

[okram]

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

https://github.com/apache/tinkerpop/pull/446#discussion_r89863961
  
--- Diff: CHANGELOG.asciidoc ---
@@ -46,6 +46,7 @@ TinkerPop 3.3.0 (Release Date: NOT OFFICIALLY RELEASED 
YET)
 * Removed `tryRandomCommit()` from `AbstractGremlinTest`.
 * Changed `gremlin-benchmark` system property for the report location to 
`benchmarkReportDir` for consistency.
 * Added SysV and systemd init scripts.
+* `valueMap` now returns a `Map` since keys could be `T.id` or 
`T.label`.
--- End diff --

Please make it read `GraphTraversal.valueMap()`.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1565:
---

I think we should treat each element type individually and not rely on a 
"cascade" of de/serialization. Thus, the {{VertexPropertySerializer}} isn't 
used to serialize the vertex properties of a vertex. Its only used when the 
vertex property is standalone. Likewise for deserialization.

We already do this with the graph serialization like {{StarGraph}}: 
http://tinkerpop.apache.org/docs/3.2.3/dev/io/#_stargraph_2

Finally, I think we should make a {{g:Graph}} type. I don't know why 
TinkerGraph has its own serialization/deserializer {{tinker:graph}} (thats 
weird).

> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and 
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official 
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to 
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded 
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded 
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex 
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new 
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired, 
> we only send/recv information that is needed for the particular 
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez edited comment on TINKERPOP-1565 at 11/28/16 7:30 PM:
-

Here is what I think the graph objects should look like:
*NOTE*: I did not include typing for the numbers to keep things clear.

{code}
{
 "@type":"g:Vertex",
 "@value": {
   "label" : "person",
   "id" : "1",
   "properties" : {
  "name" : [ {
"id" : 0,
"value" : "marko",
  } ],
  "location" : [ {
"id" : 6,
"value" : "san diego",
"properties" : {
  "startTime": 1997,
  "endTime" : 2001
}
  } ],
   }
 }
}

/

{
  "@type" : "g:Edge",
  "@value" : {
"id" : 9,
"label" : "created",
"inVLabel" : "software",
"outVLabel" : "person",
"inV" : 3,
"outV" : 0,
"properties" : {
  "weight" : 0.4
}
  }
}

/

{
  "@type" : "g:VertexProperty",
  "@value" : {
"id" : 0,
"value" : "marko",
"label" : "name",
"vertex" : 1
  }
}



{
  "@type" : "g:Property",
  "@value" : {
"key" : "weight",
"value" : 0.4,
"edge" : 9,
"vertex" : 0
  }
}

{
  "@type" : "g:Property",
  "@value" : {
"key" : "startTime",
"value" : 1997,
"vertexProperty" : 6,
"vertex" : 0
  }
}
{code}

The benefits of the above:

1. With {{getOrDefault()}} style selection from JSON, this supports both 
{{DetachXXX}} and {{ReferenceXXX}}.
2. Properties are consistent. They are just key/value map. No more needed.
3. All the information is there for attaching both {{DetachXXX}} and 
{{ReferenceXXX}}.
4. This is a very concise representation.






was (Author: okram):
Here is what I think the graph objects should look like:
*NOTE*: I did not include typing for the numbers to keep things clear.

{code}
{
 "@type":"g:Vertex",
 "@value": {
   "label" : "person",
   "id" : "1",
   "properties" : {
  "name" : [ {
"id" : 0,
"value" : "marko",
  } ],
  "location" : [ {
"id" : 6,
"value" : "san diego",
"properties" : {
  "startTime": 1997,
  "endTime" : 2001
}
  } ],
   }
 }
}
{code}

The benefits of the above:

1. With {{getOrDefault()}} style selection from JSON, this supports both 
{{DetachXXX}} and {{ReferenceXXX}}.
2. Properties are consistent. They are just key/value map. No more needed.
3. All the information is there for attaching both {{DetachXXX}} and 
{{ReferenceXXX}}.
4. This is a very concise representation.





> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and 
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official 
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to 
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded 
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded 
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex 
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new 
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired, 
> we only send/recv information 

[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1565:
---

Here is what I think the graph objects should look like:
*NOTE*: I did not include typing for the numbers to keep things clear.

{code}
{
 "@type":"g:Vertex",
 "@value": {
   "label" : "person",
   "id" : "1",
   "properties" : {
  "name" : [ {
"id" : 0,
"value" : "marko",
  } ],
  "location" : [ {
"id" : 6,
"value" : "san diego",
"properties" : {
  "startTime": 1997,
  "endTime" : 2001
}
  } ],
   }
 }
}
{code}

The benefits of the above:

1. With {{getOrDefault()}} style selection from JSON, this supports both 
{{DetachXXX}} and {{ReferenceXXX}}.
2. Properties are consistent. They are just key/value map. No more needed.
3. All the information is there for attaching both {{DetachXXX}} and 
{{ReferenceXXX}}.
4. This is a very concise representation.





> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and 
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official 
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to 
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded 
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded 
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex 
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new 
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired, 
> we only send/recv information that is needed for the particular 
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop pull request #:

[JPMoresmau]

Github user JPMoresmau commented on the pull request:


https://github.com/apache/tinkerpop/commit/4eba658bcb347679eda964c27595e5d3969a199a#commitcomment-19987727
  
In CHANGELOG.asciidoc:
In CHANGELOG.asciidoc on line 49:
Yes, of course T and not V, I'm an idiot. Technically though, 
GraphTraversal.getValueMap returns `GraphTraversal>`.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #:

[robertdale]

Github user robertdale commented on the pull request:


https://github.com/apache/tinkerpop/commit/4eba658bcb347679eda964c27595e5d3969a199a#commitcomment-19987601
  
In CHANGELOG.asciidoc:
In CHANGELOG.asciidoc on line 49:
1. Isn't it Map?
2. It should be T.id and T.label



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #446: TINKERPOP-1483: valueMap should always return string k...

[JPMoresmau]

Github user JPMoresmau commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
I've update the changelog and upgrade doc, not sure it's sufficient, please 
check! thanks!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

[ASF GitHub Bot (JIRA)]

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

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

Github user JPMoresmau commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
I've update the changelog and upgrade doc, not sure it's sufficient, please 
check! thanks!


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

[Kevin Gallardo (JIRA)]

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

Kevin Gallardo edited comment on TINKERPOP-1565 at 11/28/16 6:08 PM:
-

Also, is there a way to make the changes introduced by TINKERPOP-1520 and this 
ticket in a GraphSON 2.1 version?


was (Author: newkek):
Also, isn't there a way to make the changes introduced by TINKERPOP-1520 and 
this ticket in a GraphSON 2.1 version?

> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and 
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official 
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to 
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded 
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded 
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex 
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding 
> in {{VertexProperty}}. 
> Edge -->
> {code}
> properties : {
>   key : "aKey",
>   value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
>   key : "aKey",
>   value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and 
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and 
> is typicaly used to ensure a data rich result set. {{ReferenceElements}} 
> contain only the necessary information for attachment. I think we can support 
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new 
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired, 
> we only send/recv information that is needed for the particular 
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-1567) GraphSON deserialization fails with within('a')

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez closed TINKERPOP-1567.
-
   Resolution: Fixed
 Assignee: Marko A. Rodriguez
Fix Version/s: 3.2.4

I added a {{WhereTest}} case that is example above to {{tp32/}} and everything 
passed as expected. I suspect with all the Python GraphsON serializer work we 
have done in {{tp32/}}, this has been indirectly fixed.

{code}
---
 T E S T S
---
Running org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngineTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.781 sec - in 
org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngineTest
Running org.apache.tinkerpop.gremlin.python.jsr223.JythonTranslatorTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.289 sec - in 
org.apache.tinkerpop.gremlin.python.jsr223.JythonTranslatorTest
Running org.apache.tinkerpop.gremlin.python.jsr223.PythonGremlinScriptEngineTest
Tests run: 19, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.848 sec - in 
org.apache.tinkerpop.gremlin.python.jsr223.PythonGremlinScriptEngineTest
Running org.apache.tinkerpop.gremlin.python.jsr223.PythonProcessComputerTest
Tests run: 593, Failures: 0, Errors: 0, Skipped: 134, Time elapsed: 18.277 sec 
- in org.apache.tinkerpop.gremlin.python.jsr223.PythonProcessComputerTest
Running org.apache.tinkerpop.gremlin.python.jsr223.PythonProcessStandardTest
Tests run: 597, Failures: 0, Errors: 0, Skipped: 46, Time elapsed: 9.284 sec - 
in org.apache.tinkerpop.gremlin.python.jsr223.PythonProcessStandardTest
Running 
org.apache.tinkerpop.gremlin.python.structure.io.graphson.GraphSONReaderTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.127 sec - in 
org.apache.tinkerpop.gremlin.python.structure.io.graphson.GraphSONReaderTest
Running 
org.apache.tinkerpop.gremlin.python.structure.io.graphson.GraphSONWriterTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.067 sec - in 
org.apache.tinkerpop.gremlin.python.structure.io.graphson.GraphSONWriterTest
{code}

> GraphSON deserialization fails with within('a')
> ---
>
> Key: TINKERPOP-1567
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1567
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant, server
>Affects Versions: 3.2.3
> Environment: Demonstrated on Ubuntu 14.04 and Debian Testing
>Reporter: Branden Moore
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.4
>
>
> Using the gremlin-python interface, when I attempt to run an example from the 
> Documentation of {{where}}:
> {code}
> g.withSideEffect('a','josh','peter']).V(1).out('created').in_('created').values('name').where(P.within('a')).toList()
> {code}
> The server returns a deserialization error:
> {noformat}
> {{[WARN] OpExecutorHandler - Could not deserialize the JSON value as 
> required. Nested exception: 
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingExce[18/147]
> ould not deserialize the JSON value as required. Nested exception: 
> java.lang.IllegalStateException: 
> org.apache.tinkerpop.gremlin.process.traversal.P.within(java.la
> ng.Object)
> 
>  at [Source: 
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in
> ","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
>  line: 1, column: 248] (through reference chain: java.util.
> LinkedHashMap["step"]->java.util.ArrayList[4]->java.util.ArrayList[1])
>  
>  at [Source: 
> {"@type":"g:Bytecode","@value":{"source":[["withSideEffect","a",["josh","peter"]]],"step":[["V",{"@type":"g:Int32","@value":1}],["out","created"],["in
> ","created"],["values","name"],["where",{"@type":"g:P","@value":{"predicate":"within","value":"a"}}]]}};
>  line: 1, column: 248]
> 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: java.lang.IllegalStateException: 
> org.apache.tinkerpop.gr
> emlin.process.traversal.P.within(java.lang.Object)
>   
> at [Source: 
> 

[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
@dkuppitz -- will you handle merge and thus, do the CHANGELOG and update 
the upgrade docs on merge?


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #446: TINKERPOP-1483: valueMap should always return string k...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
@dkuppitz -- will you handle merge and thus, do the CHANGELOG and update 
the upgrade docs on merge?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1568) Change strategy application order

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1568:
---

This is a good point:

"This prevents strategies from performing global operations across the 
traversal and all decedents effectively as children will not have been 
processed by preceding strategies yet."

As a "lets see what happens," I went ahead and changed the strategy application 
order as prescribe.
  https://gist.github.com/okram/bc2c4d3161f55d220b4ca8d98678192a (hacked as 
this is not an efficient way to ultimately do this)

The standard process suite tests pass fine, but the computer process test 
suites failed in numerous places... I can't seem to find a simple explanation 
why. Anywho, seems that this change would be significant. Keeping it on the 
back burner and for a major release.



> Change strategy application order
> -
>
> Key: TINKERPOP-1568
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1568
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Bryn Cooke
>
> Given a traversal with the structure:
> a(b(),c(d()))
> Strategies are applied in the order:
> {noformat}
> StrategyA on a
> StrategyB on a
> StrategyA on b
> StrategyB on b
> StrategyA on c
> StrategyB on c
> StrategyA on d
> StrategyB on d
> {noformat}
> This prevents strategies from performing global operations across the 
> traversal and all decedents effectively as children will not have been 
> processed by preceding strategies yet.
> Say you want a strategy that compresses the entire traversal in to a string 
> for sending over the wire, you want this to happen after everything else, but 
> traversals with children will not have had their children processed.
> Ideally strategy application would be as follows:
> {noformat}
> StrategyA on a
> StrategyA on b
> StrategyA on c
> StrategyA on d
> StrategyB on a
> StrategyB on b
> StrategyB on c
> StrategyB on d
> {noformat}
> That way strategy B can check if it is being applied to the root traversal 
> and if it is it knows that A has been applied globally.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
I didn't dig into this too much just yet - I did see this in the travis 
logs:

```text
 If you want to explicitly ignore this change and provide a justification 
for it, add the following JSON snippet to your Revapi configuration under 
"revapi.ignore" path:
```

@metlos do you happen to know offhand if this means that if we add a 
breaking change of some sort that the `revapi.ignore` will just need to 
continue to fill with these exceptions we have to add? Can those be added to an 
external file somehow or do they have to be in the pom.xml? 

also - what's the reason for `.travis.install-maven.sh`? do we need a 
specific version of maven (3.3.9) for this to work?

I generally agree with the listing of initial packages to protect that 
@okram provided - i'm not sure if adding those will allow travis to pass, but I 
think we'd want to get the build working in full before merging this.


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
I didn't dig into this too much just yet - I did see this in the travis 
logs:

```text
 If you want to explicitly ignore this change and provide a justification 
for it, add the following JSON snippet to your Revapi configuration under 
"revapi.ignore" path:
```

@metlos do you happen to know offhand if this means that if we add a 
breaking change of some sort that the `revapi.ignore` will just need to 
continue to fill with these exceptions we have to add? Can those be added to an 
external file somehow or do they have to be in the pom.xml? 

also - what's the reason for `.travis.install-maven.sh`? do we need a 
specific version of maven (3.3.9) for this to work?

I generally agree with the listing of initial packages to protect that 
@okram provided - i'm not sure if adding those will allow travis to pass, but I 
think we'd want to get the build working in full before merging this.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
This requires CHANGELOG and upgrade docs too (unless a committer wants to 
take responsibility for that).


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #446: TINKERPOP-1483: valueMap should always return string k...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
This requires CHANGELOG and upgrade docs too (unless a committer wants to 
take responsibility for that).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1561) gremiln-python GraphSONWriter doesn't properly serialize long in Python 3.5

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/505
  
I have no way of checking Python 3.x, but note that everything is good for 
Python 2.x.

```
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 11:12 min
[INFO] Finished at: 2016-11-28T10:05:20-07:00
[INFO] Final Memory: 212M/1302M
[INFO] 

```

VOTE +1.


> gremiln-python GraphSONWriter doesn't properly serialize long in Python 3.5
> ---
>
> Key: TINKERPOP-1561
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1561
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.2.3
> Environment: Python 3.5
>Reporter: David M. Brown
>
> Because {{long}} doesn't exist in Python 3, we created a simple wrapper that 
> inherits from {{int}} to fill the void. After the last changes to the 
> gremlin-python {{graphson}} module, this inheritance causes our longs to be 
> serialized as {{Int32}}. For example:
> {code}
> from gremlin_python.statics import long
> from gremlin_python.structure.io.graphson import GraphSONWriter
> writer = GraphSONWriter()
> writer.toDict(1)
> {'@type': 'g:Int32', '@value': 1}
> writer.toDict(long(1))
> {'@type': 'g:Int32', '@value': 1}
> {code}
> This should be an easy fix. As far as I can see there are two main approaches:
> 1. Combine the {{Int64IO}} and {{Int32IO}} classes and perform an instance 
> check for long in the {{dictify()}} method; or,
> 2. Implement a {{long}} type that doesn't inherit from {{int}}. Here we would 
> probably want to define a variety of methods so our {{long}} emulates 
> Python's numeric object.
> Does anyone have an opinion on a preferred approach? I would probably go with 
> the first approach, but either could work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #505: TINKERPOP-1561 gremiln-python GraphSONWriter doesn't p...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/505
  
I have no way of checking Python 3.x, but note that everything is good for 
Python 2.x.

```
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 11:12 min
[INFO] Finished at: 2016-11-28T10:05:20-07:00
[INFO] Final Memory: 212M/1302M
[INFO] 

```

VOTE +1.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #446: TINKERPOP-1483: valueMap should always return string k...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
Yea, `Map` is the thing. :| ... I really don't like 
`valueMap()`. For this reason and for the `boolean` argument overload ... 
fuggly.

VOTE +1.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
I think we should start this merge off by having only the following 
packages be analyzed:

```
org.apache.tinkerpop.gremlin.structure
org.apache.tinkerpop.gremlin.structure.io
org.apache.tinkerpop.gremlin.process.computer
org.apache.tinkerpop.gremlin.process.traversal
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph
```

Those are the true core concepts. As we get comfortable with this tool and 
smarter about packaging we can add more things. 

Thoughts?


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
I think we should start this merge off by having only the following 
packages be analyzed:

```
org.apache.tinkerpop.gremlin.structure
org.apache.tinkerpop.gremlin.structure.io
org.apache.tinkerpop.gremlin.process.computer
org.apache.tinkerpop.gremlin.process.traversal
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph
```

Those are the true core concepts. As we get comfortable with this tool and 
smarter about packaging we can add more things. 

Thoughts?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1566) Kerberos authentication for gremlin-server

[Marc de Lignie (JIRA)]

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

Marc de Lignie commented on TINKERPOP-1566:
---

Gremlin-server instances in a Kerberos realm will typically need audit logging. 
I can think of three approaches for this:
 1. Add debug messages relevant to audit logging
 2. Add info messages relevant to audit logging
 3. Conditionally add info messages relevant to audit logging

Approach 1. is a no go (debug messages are not for production). Approach 2. is 
a no go too (logging personal information, also for those who not need it). 
Therefore, I propose using approach 3, with two conditional logger.info() 
statements added, one in SaslAuthenticationHandler that binds the username to 
its remote socket address, and one in AbstractEvalOpProcessor that binds each 
gremlin request to the channel's remote socket address. Here, conditional means 
something like the presence of a system property in the JAVA_OPTIONS: 
-Dgremlin.server.security.audit=true

Agree?

Cheers, Marc

> Kerberos authentication for gremlin-server
> --
>
> Key: TINKERPOP-1566
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1566
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Reporter: Marc de Lignie
>Priority: Minor
>  Labels: security
> Fix For: 3.3.0
>
>
> Gremlin server would benefit from an explicit Kerberos authentication plugin, 
> because preparing and maintaining such a plugin is nontrivial. Also, many 
> other Apache project provide kerberized services.
> In gremlin-console the standard Krb5LoginModule can be configured. 
> Gremlin-server already includes the pluggable Sasl framework that can host 
> the proposed Kerberos authentication plugin. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TINKERPOP-479) Consider Providing "getOrCreate" Functionality

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz edited comment on TINKERPOP-479 at 11/28/16 1:51 PM:


You mean {{coalesce}} should be available on the {{GraphTraversalSource}} 
level? {{g.coalesce(...)}}? Then I definitely agree, yes.


was (Author: dkuppitz):
You mean `coalesce` should be available on the `GraphTraversalSource` level? 
`g.coalesce(...)`? Then I definitely agree, yes.

> Consider Providing "getOrCreate" Functionality
> --
>
> Key: TINKERPOP-479
> URL: https://issues.apache.org/jira/browse/TINKERPOP-479
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> One of the most commonly written functions used is good ol' "getOrCreate" 
> where you want to get a {{Vertex}} if it exists or create it with supplied 
> properties if it does not.  We currently have a "helper" function for this on 
> {{ElementHelper}} 
> https://github.com/tinkerpop/tinkerpop3/blob/6d0f00865f673cb0739f6f310e1868425f732924/gremlin-core/src/main/java/com/tinkerpop/gremlin/structure/util/ElementHelper.java#L62
> but perhaps it is time to treat this issue as a first class citizen as part 
> of the Graph API.  I think that some vendors might actually be able to 
> optimize this function as well.  
> Another aspect of "getOrCreate" is "upsert" as well as options to ensure 
> uniqueness.  All of these things we've at some point or another built 
> variations of outside of TinkerPop for applications, data loading, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-479) Consider Providing "getOrCreate" Functionality

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-479:
--

You mean `coalesce` should be available on the `GraphTraversalSource` level? 
`g.coalesce(...)`? Then I definitely agree, yes.

> Consider Providing "getOrCreate" Functionality
> --
>
> Key: TINKERPOP-479
> URL: https://issues.apache.org/jira/browse/TINKERPOP-479
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> One of the most commonly written functions used is good ol' "getOrCreate" 
> where you want to get a {{Vertex}} if it exists or create it with supplied 
> properties if it does not.  We currently have a "helper" function for this on 
> {{ElementHelper}} 
> https://github.com/tinkerpop/tinkerpop3/blob/6d0f00865f673cb0739f6f310e1868425f732924/gremlin-core/src/main/java/com/tinkerpop/gremlin/structure/util/ElementHelper.java#L62
> but perhaps it is time to treat this issue as a first class citizen as part 
> of the Graph API.  I think that some vendors might actually be able to 
> optimize this function as well.  
> Another aspect of "getOrCreate" is "upsert" as well as options to ensure 
> uniqueness.  All of these things we've at some point or another built 
> variations of outside of TinkerPop for applications, data loading, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-479) Consider Providing "getOrCreate" Functionality

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-479:


hmm - i think that we've evolved to a point where this should be something for 
the traversal API and {{coalesce}} doesn't look bad for this purpose. 
[~dkuppitz] what do you think?

> Consider Providing "getOrCreate" Functionality
> --
>
> Key: TINKERPOP-479
> URL: https://issues.apache.org/jira/browse/TINKERPOP-479
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> One of the most commonly written functions used is good ol' "getOrCreate" 
> where you want to get a {{Vertex}} if it exists or create it with supplied 
> properties if it does not.  We currently have a "helper" function for this on 
> {{ElementHelper}} 
> https://github.com/tinkerpop/tinkerpop3/blob/6d0f00865f673cb0739f6f310e1868425f732924/gremlin-core/src/main/java/com/tinkerpop/gremlin/structure/util/ElementHelper.java#L62
> but perhaps it is time to treat this issue as a first class citizen as part 
> of the Graph API.  I think that some vendors might actually be able to 
> optimize this function as well.  
> Another aspect of "getOrCreate" is "upsert" as well as options to ensure 
> uniqueness.  All of these things we've at some point or another built 
> variations of outside of TinkerPop for applications, data loading, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1566) Kerberos authentication for gremlin-server

[Marc de Lignie (JIRA)]

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

Marc de Lignie commented on TINKERPOP-1566:
---

I added a failing test on branch TINKERPOP-1566 (almost equal to master) 
regarding the serialization/casting issue for Kerberos challenges, reported 
here yesterday:

https://github.com/vtslab/incubator-tinkerpop/commit/da53479ade8bd586ab48878577eefa74b1d446ac

Just uncomment shouldAuthenticateWithSerializeResultToString and run.

Cheers,Marc

> Kerberos authentication for gremlin-server
> --
>
> Key: TINKERPOP-1566
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1566
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Reporter: Marc de Lignie
>Priority: Minor
>  Labels: security
> Fix For: 3.3.0
>
>
> Gremlin server would benefit from an explicit Kerberos authentication plugin, 
> because preparing and maintaining such a plugin is nontrivial. Also, many 
> other Apache project provide kerberized services.
> In gremlin-console the standard Krb5LoginModule can be configured. 
> Gremlin-server already includes the pluggable Sasl framework that can host 
> the proposed Kerberos authentication plugin. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
Well - this isn't a rebase - it is a merge. See the ugly merge commit here: 
d49f692f890d1c868f9de674901e14c34e7c20ba 

For further explanation:

```text
D:\Data\TEMP\@Other\tinkerpop>git push origin tp31
To https://github.com/pauljackson/tinkerpop.git
! [rejected]tp31 -> tp31 (non-fast-forward)
error: failed to push some refs to 
'https://github.com/pauljackson/tinkerpop.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
```

So you had it right up to here but then probably got rattled by the message 
above and decided to then do the following:

```text
D:\Data\TEMP\@Other\tinkerpop>git pull
Merge made by the 'recursive' strategy.
```

which will do a `git merge` behind the scenes.  Your `git push` command 
should have been:

```text
git push origin tp31 --force
```

The `--force` is required because you have no re-written the git history 
for `tp31` (i.e. you moved your commit forward to the head of `tp31`) and the 
server rejected it - "force" is a way of overriding that safeguard. So - anyway 
- this could be fixed, but i'm not going to worry about it. If only two commits 
come over in the merge (i.e. your original work and the merge commit) then I 
suppose that this is fine to merge.


> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Assignee: Jason Plurad
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
Well - this isn't a rebase - it is a merge. See the ugly merge commit here: 
d49f692f890d1c868f9de674901e14c34e7c20ba 

For further explanation:

```text
D:\Data\TEMP\@Other\tinkerpop>git push origin tp31
To https://github.com/pauljackson/tinkerpop.git
! [rejected]tp31 -> tp31 (non-fast-forward)
error: failed to push some refs to 
'https://github.com/pauljackson/tinkerpop.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
```

So you had it right up to here but then probably got rattled by the message 
above and decided to then do the following:

```text
D:\Data\TEMP\@Other\tinkerpop>git pull
Merge made by the 'recursive' strategy.
```

which will do a `git merge` behind the scenes.  Your `git push` command 
should have been:

```text
git push origin tp31 --force
```

The `--force` is required because you have no re-written the git history 
for `tp31` (i.e. you moved your commit forward to the head of `tp31`) and the 
server rejected it - "force" is a way of overriding that safeguard. So - anyway 
- this could be fixed, but i'm not going to worry about it. If only two commits 
come over in the merge (i.e. your original work and the merge commit) then I 
suppose that this is fine to merge.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---