[jira] [Commented] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/714
  
It breaks other parts of the code when you attempt to modify the parent 
traversal, in particular when you remove one or more steps. I don't remember 
where the exception was thrown, but it was an IndexOutOfBoundsException. So 
apparently there's a for-loop with an upper bound that is only initialized once 
(which is good, I wouldn't like to recount the steps in each iteration).


> RangeByIsCountStrategy doesn't handle floating point numbers properly
> -
>
> Key: TINKERPOP-1782
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1782
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> See: https://groups.google.com/d/msg/gremlin-users/90IY6QMp4YQ/w60l_pfvCgAJ



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #714: TINKERPOP-1782 RangeByIsCountStrategy doesn't handle f...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/714
  
It breaks other parts of the code when you attempt to modify the parent 
traversal, in particular when you remove one or more steps. I don't remember 
where the exception was thrown, but it was an IndexOutOfBoundsException. So 
apparently there's a for-loop with an upper bound that is only initialized once 
(which is good, I wouldn't like to recount the steps in each iteration).


---

[jira] [Commented] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/714#discussion_r138748892
  
--- Diff: 
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/RangeByIsCountStrategyTest.java
 ---
@@ -99,6 +99,9 @@
 {__.and(__.out().count().is(0), __.in().count().is(1)), 
__.and(__.not(__.out()), __.in().limit(2).count().is(1))},
 {__.and(__.out().count().is(1), __.in().count().is(0)), 
__.and(__.out().limit(2).count().is(1), __.not(__.in()))},
 {__.or(__.out().count().is(0), __.in().count().is(0)), 
__.or(__.not(__.out()), __.not(__.in()))},
+{__.path().filter(__.count().is(gte(0.5))).limit(5), 
__.path().identity().limit(5)}, // unfortunately we can't just remove the 
filter step
--- End diff --

Why can't you remove the `filter()` step? That is, why the `identity()` 
step replacement?


> RangeByIsCountStrategy doesn't handle floating point numbers properly
> -
>
> Key: TINKERPOP-1782
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1782
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> See: https://groups.google.com/d/msg/gremlin-users/90IY6QMp4YQ/w60l_pfvCgAJ



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #714: TINKERPOP-1782 RangeByIsCountStrategy doesn't h...

[okram]

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

https://github.com/apache/tinkerpop/pull/714#discussion_r138748892
  
--- Diff: 
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/RangeByIsCountStrategyTest.java
 ---
@@ -99,6 +99,9 @@
 {__.and(__.out().count().is(0), __.in().count().is(1)), 
__.and(__.not(__.out()), __.in().limit(2).count().is(1))},
 {__.and(__.out().count().is(1), __.in().count().is(0)), 
__.and(__.out().limit(2).count().is(1), __.not(__.in()))},
 {__.or(__.out().count().is(0), __.in().count().is(0)), 
__.or(__.not(__.out()), __.not(__.in()))},
+{__.path().filter(__.count().is(gte(0.5))).limit(5), 
__.path().identity().limit(5)}, // unfortunately we can't just remove the 
filter step
--- End diff --

Why can't you remove the `filter()` step? That is, why the `identity()` 
step replacement?


---

[jira] [Commented] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

[ASF GitHub Bot (JIRA)]

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

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

GitHub user dkuppitz opened a pull request:

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

TINKERPOP-1782 RangeByIsCountStrategy doesn't handle floating point numbers 
properly

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

Fixed a bug in `RangeByIsCountStrategy` that led to unexpected behaviors 
when predicates were used with floating point numbers.

VOTE: +1

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

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

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

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

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

This closes #714


commit 8c26a33658a69b9d9e2295662e063345eca2ae76
Author: Daniel Kuppitz 
Date:   2017-09-13T21:08:07Z

Fixed a bug in `RangeByIsCountStrategy` that led to unexpected behaviors 
when predicates were used with floating point numbers.




> RangeByIsCountStrategy doesn't handle floating point numbers properly
> -
>
> Key: TINKERPOP-1782
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1782
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> See: https://groups.google.com/d/msg/gremlin-users/90IY6QMp4YQ/w60l_pfvCgAJ



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #714: TINKERPOP-1782 RangeByIsCountStrategy doesn't h...

[dkuppitz]

GitHub user dkuppitz opened a pull request:

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

TINKERPOP-1782 RangeByIsCountStrategy doesn't handle floating point numbers 
properly

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

Fixed a bug in `RangeByIsCountStrategy` that led to unexpected behaviors 
when predicates were used with floating point numbers.

VOTE: +1

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

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

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

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

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

This closes #714


commit 8c26a33658a69b9d9e2295662e063345eca2ae76
Author: Daniel Kuppitz 
Date:   2017-09-13T21:08:07Z

Fixed a bug in `RangeByIsCountStrategy` that led to unexpected behaviors 
when predicates were used with floating point numbers.




---

[jira] [Commented] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1782:
---

One more interesting observation:

{noformat}
gremlin> 
g.V(1).repeat(out()).until(__.not(outE())).path().filter(unfold().count().is(gte(2.5)))
gremlin> 
g.V(1).repeat(out()).until(__.not(outE())).path().filter(unfold().count().is(gt(2.5)))
==>[v[1],v[4],v[5]]
==>[v[1],v[4],v[3]]
{noformat}

> RangeByIsCountStrategy doesn't handle floating point numbers properly
> -
>
> Key: TINKERPOP-1782
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1782
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> See: https://groups.google.com/d/msg/gremlin-users/90IY6QMp4YQ/w60l_pfvCgAJ



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1746) Better error message on wrong ordering of emit()/until()/has()

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/711
  
Nvm, I just saw the ticket description (link is missing here and I was too 
lazy to look it up).

VOTE: +1


> Better error message on wrong ordering of emit()/until()/has()
> --
>
> Key: TINKERPOP-1746
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1746
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.5
> Environment: TinkerPop 3.2.5
>Reporter: DOAN DuyHai
>Priority: Trivial
>
> {code}
> gremlin> g.withSack([] as Set).
> ..1>   V().
> ..2>   emit().
> ..3>   has("station", "name", "South Kensington").
> ..4>   repeat(bothE("connectedTo").sack{s,v -> s.add(v); return 
> s;}.by("line").otherV().simplePath()).times(2).
> ..5>   sack()
> NullPointerException
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #711: TINKERPOP-1746: Better error message on wrong ordering...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/711
  
Nvm, I just saw the ticket description (link is missing here and I was too 
lazy to look it up).

VOTE: +1


---

[jira] [Commented] (TINKERPOP-1746) Better error message on wrong ordering of emit()/until()/has()

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/711
  
Which scenario would end up throwing this exception? Tried this:

```
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().repeat().times(2)
java.lang.NullPointerException
```

... but it's obviously still a NPE thrown in [line 
67](https://github.com/apache/tinkerpop/blob/53db262511e9d84b1262522fc841ded825df4fc6/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/branch/RepeatStep.java#L67).


> Better error message on wrong ordering of emit()/until()/has()
> --
>
> Key: TINKERPOP-1746
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1746
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.5
> Environment: TinkerPop 3.2.5
>Reporter: DOAN DuyHai
>Priority: Trivial
>
> {code}
> gremlin> g.withSack([] as Set).
> ..1>   V().
> ..2>   emit().
> ..3>   has("station", "name", "South Kensington").
> ..4>   repeat(bothE("connectedTo").sack{s,v -> s.add(v); return 
> s;}.by("line").otherV().simplePath()).times(2).
> ..5>   sack()
> NullPointerException
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #711: TINKERPOP-1746: Better error message on wrong ordering...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/711
  
Which scenario would end up throwing this exception? Tried this:

```
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().repeat().times(2)
java.lang.NullPointerException
```

... but it's obviously still a NPE thrown in [line 
67](https://github.com/apache/tinkerpop/blob/53db262511e9d84b1262522fc841ded825df4fc6/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/branch/RepeatStep.java#L67).


---

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1474:
-

ok - true - we could probably make that section more clear

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>Assignee: stephen mallette
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[Kevin Gallardo (JIRA)]

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

Kevin Gallardo commented on TINKERPOP-1474:
---

re: GraphSON:

The GraphSON spec [as detailed 
here|http://tinkerpop.apache.org/docs/3.3.0/dev/io/#_vertex_3] mentions 
properties being serialized as part of the Vertex and that's what I was 
referring to If Tinkerpop were to decide that properties are fully separate 
from Vertex then the GraphSON spec should reflect it, since in GraphSON there 
is no notion of "g:DetachedVertex" or "g:ReferenceVertex" - everything is 
Vertex, so the serialization specs should align with that I think.

About properties, (I know this is a long term goal and you're still only 
thinking about it but) to me it seems the most natural that Properties get 
serialized separately from Vertices and Edges and simply contain a reference 
(ID) to their parent element to allow re-attaching to it.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>Assignee: stephen mallette
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1474:
-

> So the only way to gather properties will be explicitly through the traversal 
> then

Yes - i think it is analogous to standard SQL practices where you typically 
don't do {{select * from table}}. you only request the fields that you want - 
same premise for gremlin and graphs. there were a number of discussions on this 
in the dev list where consensus always seemed to settle on not trying to 
implement property support across glvs so I figured this one didn't need to 
stay open any longer.

> Just realized that the GraphSON specification will need to be updated once 
> that happens.

again - not something that would happen any time soon. no one every sounded in 
favor of doing a takeaway of from the java folks who are still getting 
properties, so I don't know that GraphSON's spec needs to change. Also, 
GraphSON is still a file storage format for a full graph so properties still 
need to be serializable in that sense. there still are some odd sticking points 
in my mind, like what constitutes a subgraph with respect to properties (not 
that GLVs can work with those directly anyway, which seems like a major missing 
piece of functionality in my mind). Anywayall stuff for the future

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>Assignee: stephen mallette
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[Kevin Gallardo (JIRA)]

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

Kevin Gallardo commented on TINKERPOP-1474:
---

So the only way to gather properties will be explicitly through the traversal 
then, I guess, interesting. Makes sense to me.

Just realized that the GraphSON specification will need to be updated once that 
happens.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>Assignee: stephen mallette
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1474:
-

> so is the goal for the Java GLV to have the Vertex class be removed of its 
> Properties methods? 

If we're talking about a distant future for TinkerPop 4.x then, yes, there will 
only be reference vertices/edges. For now, in TinkerPop 3.x I think we've gone 
too far down the path of enabling properties in Java to ever really take them 
away. We can only hide them via TINKERPOP-1701 and encourage users to think 
property-less. I think we just want to align 3.x with the idea of where things 
are headed further in the future. So the discrepancy of properties will 
basically remain between java and python, js, etc, but we will likely shift 
defaults over time to not include properties for Java (with java users having 
the option to go back to including properties if they like as a method of 
backward compatibility). 

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>Assignee: stephen mallette
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[Kevin Gallardo (JIRA)]

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

Kevin Gallardo commented on TINKERPOP-1474:
---

[~spmallette] so is the goal for the Java GLV to have the Vertex class be 
removed of its Properties methods? Like {{v.property('name')}}, etc etc

I think the issue here was more about the Graph {{structure}} objects like 
Vertex, Edge, and so on which do not have a properties in the class definition 
itself. In Java, whether the object sent over the wire is a Detached or 
Reference element, the object returned by the Tinkerpop API always extends 
Vertex, which has an API for properties even though if the object sent is a 
Reference, calling to properties will return empty results. In the Python GLV, 
currently whether a Vertex sent is Detached or Reference, the Vertex class does 
not have an API to gather properties out of the Vertex.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>Assignee: stephen mallette
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1782:
---

Another obscurity:

{noformat}
gremlin> 
g.V(1).repeat(out()).until(outE().count().is(0)).path().filter(unfold().count().is(gte(1.5))).explain()
==>Traversal Explanation
=
Original Traversal [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until([VertexStep(OUT,edge), 
CountGlobalStep, IsStep(eq(0))]),emit(false)), PathStep, Trave
  rsalFilterStep([UnfoldStep, 
CountGlobalStep, IsStep(gte(1.5))])]

ConnectiveStrategy   [D]   [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until([VertexStep(OUT,edge), 
CountGlobalStep, IsStep(eq(0))]),emit(false)), PathStep, Trave
  rsalFilterStep([UnfoldStep, 
CountGlobalStep, IsStep(gte(1.5))])]
MatchPredicateStrategy   [O]   [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until([VertexStep(OUT,edge), 
CountGlobalStep, IsStep(eq(0))]),emit(false)), PathStep, Trave
  rsalFilterStep([UnfoldStep, 
CountGlobalStep, IsStep(gte(1.5))])]
RepeatUnrollStrategy [O]   [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until([VertexStep(OUT,edge), 
CountGlobalStep, IsStep(eq(0))]),emit(false)), PathStep, Trave
  rsalFilterStep([UnfoldStep, 
CountGlobalStep, IsStep(gte(1.5))])]
FilterRankingStrategy[O]   [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until([VertexStep(OUT,edge), 
CountGlobalStep, IsStep(eq(0))]),emit(false)), PathStep, Trave
  rsalFilterStep([UnfoldStep, 
CountGlobalStep, IsStep(gte(1.5))])]
CountStrategy[O]   [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), 
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)), PathStep, 
TraversalFilterStep([Unfol
  dStep])]
InlineFilterStrategy [O]   [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), 
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)), PathStep, 
TraversalFilterStep([Unfol
  dStep])]
IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), 
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)), PathStep, 
TraversalFilterStep([Unfol
  dStep])]
AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), 
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)), PathStep, 
TraversalFilterStep([Unfol
  dStep])]
PathRetractionStrategy   [O]   [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until([VertexStep(OUT,edge), 
RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))]),emit(fa
  lse)), PathStep, 
TraversalFilterStep([UnfoldStep, RangeGlobalStep(0,1), CountGlobalStep, 
IsStep(gte(1.5))])]
LazyBarrierStrategy  [O]   [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until([VertexStep(OUT,edge), 
RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))]),emit(fa
  lse)), PathStep, 
TraversalFilterStep([UnfoldStep, RangeGlobalStep(0,1), CountGlobalStep, 
IsStep(gte(1.5))])]
TinkerGraphCountStrategy [P]   [GraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until([VertexStep(OUT,edge), 
RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))]),emit(fa
  lse)), PathStep, 
TraversalFilterStep([UnfoldStep, RangeGlobalStep(0,1), CountGlobalStep, 
IsStep(gte(1.5))])]
TinkerGraphStepStrategy  [P]   [TinkerGraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until([VertexStep(OUT,edge), 
RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))]),e
  mit(false)), PathStep, 
TraversalFilterStep([UnfoldStep, RangeGlobalStep(0,1), CountGlobalStep, 
IsStep(gte(1.5))])]
ProfileStrategy  [F]   [TinkerGraphStep(vertex,[1]), 
RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until([VertexStep(OUT,edge), 
RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))]),e
  mit(false)), PathStep, 
TraversalFilterStep([UnfoldStep, RangeGlobalStep(0,1), CountGlobalStep, 
IsStep(gte(1.5))])]
StandardVerificationStrategy [V]   

[jira] [Commented] (TINKERPOP-1463) Improve has(propertyKey, traversal)

[Robert Dale (JIRA)]

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

Robert Dale commented on TINKERPOP-1463:


Actually, now that I understand it, I think it makes sense the way it is.  It's 
a filter traversal and not a value traversal if I can put it that way.
{{Remove the traverser if its object does not yield a result through the 
traversal off the property value.}} now makes more sense. I think we just need 
an example in the docs.

Trying to think through using {{select()}} or a value-producing traversal.  It 
seems to make sense when you want equals. But how would you use it for other 
predicates (e.g. {{gte()}})?  

Adding an example of how to use the current step implementation for 
multi-valued 'objects' in a create or update traversal.

{code}
data = [['a':'marko','b':29], ['a':'jimbo','b':53]]
g.inject(data).unfold().
as('list').select('a').as('name').
select('list').select('b').as('age').
coalesce(__.V().hasLabel('person').has('name', 
__.where(eq('name'))).has('age',__.where(eq('age'))),
 __.addV('person').property('name', 
select('name')).property('age',select('age'))
).valueMap(true)
{code}


> Improve has(propertyKey, traversal)
> ---
>
> Key: TINKERPOP-1463
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1463
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.5
>Reporter: Daniel Kuppitz
>
> Two issues here:
> {{.has(propertyKey, traversal)}} kinda doesn't work as expected:
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.addV(label, "software",  "lang", "python")
> ==>v[12]
> gremlin> g.V().has("name","lop").values("lang").as("l").V().has("lang", 
> select("l"))
> ==>v[3]
> ==>v[5]
> ==>v[12]
> gremlin> g.V().has("name","lop").values("lang").as("l").V().has("lang", 
> __.where(eq("l")))
> ==>v[3]
> ==>v[5]
> {code}
> From a user perspective {{.has("lang", select("l"))}} is / would be 
> self-explanatory, {{.has("lang", __.where(eq("l")))}} on the other hand is 
> confusing and I don't see good use-cases for it, as you could also write:
> {code}
> g.V().has("name","lop").values("lang").as("l").V().where(values("lang").as("l"))
> {code}
> The second issue or follow-up issue is, that has-traversal should be folded 
> into the {{GraphStep}}, so that the mid-traversal {{V()}} is not a full graph 
> scan. Given the traversal:
> {code}
> g.V().has("name","lop").values("lang").as("l").V().has("lang", select("l"))
> {code}
> ... we would know the value of {{"l"}} at runtime. Thus it's not much 
> different from
> {code}
> g.V().has("name","lop").values("lang").as("l").V().has("lang", "java")
> {code}
> The only difference is that the latter traversal knows that the {{lang}} 
> value is {{java}} at compile time and the former traversal only knows it at 
> runtime. In either case the value is known before it's needed for the 
> mid-traversal {{V().has(...)}} lookup part.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1782:
---

{noformat}
gremlin> 
g.V(1).repeat(out()).until(outE().count().is(0)).path().filter(unfold().count().is(gte(2)))
==>[v[1],v[3]]
==>[v[1],v[2]]
==>[v[1],v[4],v[5]]
==>[v[1],v[4],v[3]]
gremlin> 
g.V(1).repeat(out()).until(outE().count().is(0)).path().filter(unfold().count().is(gte(3)))
==>[v[1],v[4],v[5]]
==>[v[1],v[4],v[3]]
gremlin> 
g.V(1).repeat(out()).until(outE().count().is(0)).path().filter(unfold().count().is(gte(1.5)))
gremlin> 
g.V(1).repeat(out()).until(outE().count().is(0)).path().filter(unfold().count().is(gte(2.5)))
{noformat}

> RangeByIsCountStrategy doesn't handle floating point numbers properly
> -
>
> Key: TINKERPOP-1782
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1782
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> See: https://groups.google.com/d/msg/gremlin-users/90IY6QMp4YQ/w60l_pfvCgAJ



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TINKERPOP-1782) RangeByIsCountStrategy doesn't handle floating point numbers properly

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-1782:
-

 Summary: RangeByIsCountStrategy doesn't handle floating point 
numbers properly
 Key: TINKERPOP-1782
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1782
 Project: TinkerPop
  Issue Type: Bug
Affects Versions: 3.2.6
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz


See: https://groups.google.com/d/msg/gremlin-users/90IY6QMp4YQ/w60l_pfvCgAJ



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1761) GremlinExecutor: Timeout future not cancelled on successful script evaluation

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/709
  
@ko-mueller thanks for submitting this. I just wanted to let you know that 
it may take some time to get this merged. Every time this area of code gets 
changed there is suffering, so I'd like to be sure adding this code back 
doesn't create some new subtle issue that we solved with TINKERPOP-1714.


> GremlinExecutor: Timeout future not cancelled on successful script evaluation
> -
>
> Key: TINKERPOP-1761
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1761
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.6
>Reporter: Konstantin Müller
>
> This bug seems to be introduced by TINKERPOP-1714. The timeout future in 
> GremlinExecutor.eval() is not cancelled when the evaluation future is 
> completed successfully before the timeout (lines 304ff). This was done 
> correctly before the changes introduced by TINKERPOP-1714. Code to reproduce:
> {code:java}
> try (GremlinExecutor executor = 
> GremlinExecutor.build().scriptEvaluationTimeout(15_000).create()) {
>   executor.eval("1+1").get();
> } catch (Exception e) {
>   // NOOP
> }
> {code}
> When the code leaves the try-block it calls GremlinExecutor.close() which 
> will clean up executorService and scheduledExecutorService, but because the 
> timeout future is not cancelled this will hang until the future is finished 
> (here 15s).
> Workaround: Provide an own ExecutorService when constructing a 
> GremlinExecutor instance and cancel all tasks when the script evaluation is 
> finished successfully.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #709: TINKERPOP-1761: Cancel script evaluation timeout

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/709
  
@ko-mueller thanks for submitting this. I just wanted to let you know that 
it may take some time to get this merged. Every time this area of code gets 
changed there is suffering, so I'd like to be sure adding this code back 
doesn't create some new subtle issue that we solved with TINKERPOP-1714.


---

[GitHub] tinkerpop issue #704: TINKERPOP-1766 Gremlin.Net: Add handling for closed co...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/704
  
VOTE +1


---

[jira] [Commented] (TINKERPOP-1766) Gremlin.Net: Closed connections should not be re-used

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/704
  
VOTE +1


> Gremlin.Net: Closed connections should not be re-used 
> --
>
> Key: TINKERPOP-1766
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1766
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Florian Hockmann
>
> The driver of Gremlin.Net is kept very simle which holds especially true for 
> the {{ConnectionPool}}. It simply returns every connection to its pool of 
> usable connections that was {{disposed}} by the client. Unfortunately, this 
> also applies in case the submit failed due to an already closed connection 
> which means that the client will get the closed connection back from the 
> {{ConnectionPool}} later and continues trying to submit messages over this 
> closed connection.
> This can be fixed by checking whether the {{Connection}} is still open before 
> adding it back to the {{ConnectionPool}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1692) Bump to Neo4j 3.2.3

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/680
  
VOTE: +1


> Bump to Neo4j 3.2.3
> ---
>
> Key: TINKERPOP-1692
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1692
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: neo4j
>Affects Versions: 3.2.5
>Reporter: stephen mallette
> Fix For: 3.3.1
>
>
> There is a newer version of Neo4j available - 
> https://mvnrepository.com/artifact/org.neo4j/neo4j-tinkerpop-api-impl/0.4-3.0.3



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Some JIRA adjustments

[Stephen Mallette]

That was my take - yes - i should have wrote that in my conclusion. I've
already updated the current tickets to include both versions. don't think i
missed any.

On Wed, Sep 13, 2017 at 8:42 AM, Daniel Kuppitz  wrote:

> Do we agree now, that Fix Version should contain all affected versions?
>
> Cheers,
> Daniel
>
>
> On Sep 13, 2017 5:11 AM, "Stephen Mallette"  wrote:
>
> > Sorry for all the noise on the list with all those JIRA updates but I've
> > basically gotten our process changes into place at this point. I've
> created
> > the new language specific components and re-assigned all the old
> > language-variants components - language-variants is no longer in use and
> > has been deleted. I also removed "Fix version" assignments - they will
> only
> > be added when we actually complete them (thus preventing future dev list
> > noise on release).
> >
> >
> >
> >
> > On Mon, Sep 11, 2017 at 8:13 AM, Jorge Bay Gondra <
> > jorge.gon...@datastax.com
> > > wrote:
> >
> > > I'm +1 on adding all fix versions that it was applied to.
> > > I'm +1 on adding a component per GLV.
> > >
> > > On Mon, Sep 11, 2017 at 1:07 PM, Robert Dale 
> wrote:
> > >
> > > > +1 for labeling all versions applied to
> > > >
> > > >
> > > >
> > > > Robert Dale
> > > >
> > > > On Mon, Sep 11, 2017 at 6:46 AM, Stephen Mallette <
> > spmalle...@gmail.com>
> > > > wrote:
> > > >
> > > > > I thought about the "Fix version" situation - I guess I don't
> really
> > > care
> > > > > which way we do it so long as it is consistent. If it is more
> > intuitive
> > > > to
> > > > > everyone to add all the versions that a fix went in on then i'm
> fine
> > to
> > > > do
> > > > > that. However, I do think the CHANGELOG is cleaner to look at
> without
> > > all
> > > > > the duplication, so if we did go down that path the release manager
> > > would
> > > > > just need to make sure that the appropriate JIRAs were filtered out
> > > > which I
> > > > > suppose isn't too hard. Anyone prefer that we assign all the fix
> > > versions
> > > > > as necessary in JIRA?
> > > > >
> > > > > On Fri, Sep 8, 2017 at 9:40 AM, Stephen Mallette <
> > spmalle...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > You would only know through tribal knowedge and the changelog I
> > > guess.
> > > > > >
> > > > > > sucks - i just realized that there are duplicates all through the
> > > > > > changelog because there's been spotty application of a single fix
> > > > > version.
> > > > > > dah
> > > > > >
> > > > > > On Fri, Sep 8, 2017 at 9:33 AM, Daniel Kuppitz 
> > > > wrote:
> > > > > >
> > > > > >> But who will remember a few months after a release, that it was
> > > 3.3.1
> > > > > that
> > > > > >> went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in
> > the
> > > > fix
> > > > > >> version, I know it must be somewhere in the 3.3 line, too, but I
> > > > > wouldn't
> > > > > >> know that it was 3.3.1 for example. That's why I always prefer
> to
> > > > > specify
> > > > > >> both / all versions.
> > > > > >>
> > > > > >> Cheers,
> > > > > >> Daniel
> > > > > >>
> > > > > >>
> > > > > >> On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette <
> > > > spmalle...@gmail.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > a while back we'd decided that since all fixes roll forward to
> > > other
> > > > > >> > releases, that we would only add the fix version to the lowest
> > > > common
> > > > > >> > release. so if you fix something 3.2.7 then it will
> > automatically
> > > be
> > > > > >> > included in 3.3.1 (we've not had a case yet where something is
> > > only
> > > > > >> fixed
> > > > > >> > in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7.
> > > From
> > > > a
> > > > > >> > reporting perspective this approach of adding just one fix
> > version
> > > > > works
> > > > > >> > nicely because when we release we can just filter JIRA on the
> > > > specific
> > > > > >> > version we are releasing without any additional filtering
> (which
> > > is
> > > > > how
> > > > > >> we
> > > > > >> > add those tickets to the changelog on release).
> > > > > >> >
> > > > > >> > On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz
>  > >
> > > > > wrote:
> > > > > >> >
> > > > > >> > > >
> > > > > >> > > >   a. reserve "fix version" for when we actually close the
> > > ticket
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > That's how I always used to do it. However, sometimes (just
> > > > > recently)
> > > > > >> I
> > > > > >> > > noticed that you took away one version. The fix went into
> > tp32/
> > > > and
> > > > > >> then
> > > > > >> > > got merged into master/. So it will end up being part of
> 3.2.7
> > > and
> > > > > >> 3.3.1
> > > > > >> > > and that's what I was using for the Fix Version. But if I
> > > remember
> > > > > >> > > correctly, you removed 3.3.1 from the Fix Version
> afterwards.
> > > > Why's
> > > > > >> that?
> > > > > >> > >

Re: [DISCUSS] Some JIRA adjustments

[Daniel Kuppitz]

Do we agree now, that Fix Version should contain all affected versions?

Cheers,
Daniel


On Sep 13, 2017 5:11 AM, "Stephen Mallette"  wrote:

> Sorry for all the noise on the list with all those JIRA updates but I've
> basically gotten our process changes into place at this point. I've created
> the new language specific components and re-assigned all the old
> language-variants components - language-variants is no longer in use and
> has been deleted. I also removed "Fix version" assignments - they will only
> be added when we actually complete them (thus preventing future dev list
> noise on release).
>
>
>
>
> On Mon, Sep 11, 2017 at 8:13 AM, Jorge Bay Gondra <
> jorge.gon...@datastax.com
> > wrote:
>
> > I'm +1 on adding all fix versions that it was applied to.
> > I'm +1 on adding a component per GLV.
> >
> > On Mon, Sep 11, 2017 at 1:07 PM, Robert Dale  wrote:
> >
> > > +1 for labeling all versions applied to
> > >
> > >
> > >
> > > Robert Dale
> > >
> > > On Mon, Sep 11, 2017 at 6:46 AM, Stephen Mallette <
> spmalle...@gmail.com>
> > > wrote:
> > >
> > > > I thought about the "Fix version" situation - I guess I don't really
> > care
> > > > which way we do it so long as it is consistent. If it is more
> intuitive
> > > to
> > > > everyone to add all the versions that a fix went in on then i'm fine
> to
> > > do
> > > > that. However, I do think the CHANGELOG is cleaner to look at without
> > all
> > > > the duplication, so if we did go down that path the release manager
> > would
> > > > just need to make sure that the appropriate JIRAs were filtered out
> > > which I
> > > > suppose isn't too hard. Anyone prefer that we assign all the fix
> > versions
> > > > as necessary in JIRA?
> > > >
> > > > On Fri, Sep 8, 2017 at 9:40 AM, Stephen Mallette <
> spmalle...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > You would only know through tribal knowedge and the changelog I
> > guess.
> > > > >
> > > > > sucks - i just realized that there are duplicates all through the
> > > > > changelog because there's been spotty application of a single fix
> > > > version.
> > > > > dah
> > > > >
> > > > > On Fri, Sep 8, 2017 at 9:33 AM, Daniel Kuppitz 
> > > wrote:
> > > > >
> > > > >> But who will remember a few months after a release, that it was
> > 3.3.1
> > > > that
> > > > >> went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in
> the
> > > fix
> > > > >> version, I know it must be somewhere in the 3.3 line, too, but I
> > > > wouldn't
> > > > >> know that it was 3.3.1 for example. That's why I always prefer to
> > > > specify
> > > > >> both / all versions.
> > > > >>
> > > > >> Cheers,
> > > > >> Daniel
> > > > >>
> > > > >>
> > > > >> On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette <
> > > spmalle...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > a while back we'd decided that since all fixes roll forward to
> > other
> > > > >> > releases, that we would only add the fix version to the lowest
> > > common
> > > > >> > release. so if you fix something 3.2.7 then it will
> automatically
> > be
> > > > >> > included in 3.3.1 (we've not had a case yet where something is
> > only
> > > > >> fixed
> > > > >> > in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7.
> > From
> > > a
> > > > >> > reporting perspective this approach of adding just one fix
> version
> > > > works
> > > > >> > nicely because when we release we can just filter JIRA on the
> > > specific
> > > > >> > version we are releasing without any additional filtering (which
> > is
> > > > how
> > > > >> we
> > > > >> > add those tickets to the changelog on release).
> > > > >> >
> > > > >> > On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz  >
> > > > wrote:
> > > > >> >
> > > > >> > > >
> > > > >> > > >   a. reserve "fix version" for when we actually close the
> > ticket
> > > > >> > >
> > > > >> > >
> > > > >> > > That's how I always used to do it. However, sometimes (just
> > > > recently)
> > > > >> I
> > > > >> > > noticed that you took away one version. The fix went into
> tp32/
> > > and
> > > > >> then
> > > > >> > > got merged into master/. So it will end up being part of 3.2.7
> > and
> > > > >> 3.3.1
> > > > >> > > and that's what I was using for the Fix Version. But if I
> > remember
> > > > >> > > correctly, you removed 3.3.1 from the Fix Version afterwards.
> > > Why's
> > > > >> that?
> > > > >> > >
> > > > >> > > Cheers,
> > > > >> > > Daniel
> > > > >> > >
> > > > >> > >
> > > > >> > > On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette <
> > > > >> spmalle...@gmail.com>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > Two quick ideas I'd like everyone to consider with respect
> to
> > > > JIRA:
> > > > >> > > >
> > > > >> > > > 1. Add "component" types for each GLV rather than just the
> > > generic
> > > > >> > > > "language variant" one we have now
> > > > >> > > > 2. Remove the "fix version" currently assigned to all 

Re: [DISCUSS] Some JIRA adjustments

[Stephen Mallette]

Sorry for all the noise on the list with all those JIRA updates but I've
basically gotten our process changes into place at this point. I've created
the new language specific components and re-assigned all the old
language-variants components - language-variants is no longer in use and
has been deleted. I also removed "Fix version" assignments - they will only
be added when we actually complete them (thus preventing future dev list
noise on release).




On Mon, Sep 11, 2017 at 8:13 AM, Jorge Bay Gondra  wrote:

> I'm +1 on adding all fix versions that it was applied to.
> I'm +1 on adding a component per GLV.
>
> On Mon, Sep 11, 2017 at 1:07 PM, Robert Dale  wrote:
>
> > +1 for labeling all versions applied to
> >
> >
> >
> > Robert Dale
> >
> > On Mon, Sep 11, 2017 at 6:46 AM, Stephen Mallette 
> > wrote:
> >
> > > I thought about the "Fix version" situation - I guess I don't really
> care
> > > which way we do it so long as it is consistent. If it is more intuitive
> > to
> > > everyone to add all the versions that a fix went in on then i'm fine to
> > do
> > > that. However, I do think the CHANGELOG is cleaner to look at without
> all
> > > the duplication, so if we did go down that path the release manager
> would
> > > just need to make sure that the appropriate JIRAs were filtered out
> > which I
> > > suppose isn't too hard. Anyone prefer that we assign all the fix
> versions
> > > as necessary in JIRA?
> > >
> > > On Fri, Sep 8, 2017 at 9:40 AM, Stephen Mallette  >
> > > wrote:
> > >
> > > > You would only know through tribal knowedge and the changelog I
> guess.
> > > >
> > > > sucks - i just realized that there are duplicates all through the
> > > > changelog because there's been spotty application of a single fix
> > > version.
> > > > dah
> > > >
> > > > On Fri, Sep 8, 2017 at 9:33 AM, Daniel Kuppitz 
> > wrote:
> > > >
> > > >> But who will remember a few months after a release, that it was
> 3.3.1
> > > that
> > > >> went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in the
> > fix
> > > >> version, I know it must be somewhere in the 3.3 line, too, but I
> > > wouldn't
> > > >> know that it was 3.3.1 for example. That's why I always prefer to
> > > specify
> > > >> both / all versions.
> > > >>
> > > >> Cheers,
> > > >> Daniel
> > > >>
> > > >>
> > > >> On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette <
> > spmalle...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > a while back we'd decided that since all fixes roll forward to
> other
> > > >> > releases, that we would only add the fix version to the lowest
> > common
> > > >> > release. so if you fix something 3.2.7 then it will automatically
> be
> > > >> > included in 3.3.1 (we've not had a case yet where something is
> only
> > > >> fixed
> > > >> > in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7.
> From
> > a
> > > >> > reporting perspective this approach of adding just one fix version
> > > works
> > > >> > nicely because when we release we can just filter JIRA on the
> > specific
> > > >> > version we are releasing without any additional filtering (which
> is
> > > how
> > > >> we
> > > >> > add those tickets to the changelog on release).
> > > >> >
> > > >> > On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz 
> > > wrote:
> > > >> >
> > > >> > > >
> > > >> > > >   a. reserve "fix version" for when we actually close the
> ticket
> > > >> > >
> > > >> > >
> > > >> > > That's how I always used to do it. However, sometimes (just
> > > recently)
> > > >> I
> > > >> > > noticed that you took away one version. The fix went into tp32/
> > and
> > > >> then
> > > >> > > got merged into master/. So it will end up being part of 3.2.7
> and
> > > >> 3.3.1
> > > >> > > and that's what I was using for the Fix Version. But if I
> remember
> > > >> > > correctly, you removed 3.3.1 from the Fix Version afterwards.
> > Why's
> > > >> that?
> > > >> > >
> > > >> > > Cheers,
> > > >> > > Daniel
> > > >> > >
> > > >> > >
> > > >> > > On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette <
> > > >> spmalle...@gmail.com>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Two quick ideas I'd like everyone to consider with respect to
> > > JIRA:
> > > >> > > >
> > > >> > > > 1. Add "component" types for each GLV rather than just the
> > generic
> > > >> > > > "language variant" one we have now
> > > >> > > > 2. Remove the "fix version" currently assigned to all open
> > issues
> > > >> > > >   a. reserve "fix version" for when we actually close the
> ticket
> > > >> > > >   b. this will prevent the mass of emails that come out every
> > time
> > > >> we
> > > >> > > > release and have to move forward all the "fix version" of
> issues
> > > >> that
> > > >> > > > didn't close
> > > >> > > >   c. i sense many of the items marked for completion in
> certain
> > > >> > versions
> > > >> > > > are no longer relevant - 

[jira] [Updated] (TINKERPOP-743) Support "barrier syntax" in step labels.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-743:
---
Fix Version/s: (was: 3.2.7)

> Support "barrier syntax" in step labels.
> 
>
> Key: TINKERPOP-743
> URL: https://issues.apache.org/jira/browse/TINKERPOP-743
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>Priority: Minor
>  Labels: breaking
>
> Here is a basic recommendation algorithm that we currently can not do in 
> match().
> {code}
> g.V(1).as('a').out('likes').aggregate('x'). // what does v[1] like
> in('likes').where(neq('a')).// who else likes those things 
> that are not v[1]
> out('likes').where(not(within('x')).// what do those people like that 
> v[1] doesn't already like
> groupCount()// count the number of times each 
> liked thing is seen
> {code}
> Why can't we do this in match()? Because we can not aggregate (well, we can, 
> but bare with me). The best we can do is:
> {code}
> g.V(1).match('a',
> as('a').out('likes').as('b'),
> as('b').in('likes').as('c'),
> as('c').out('likes').as('d'),
> where('d',neq('b')),
> where('a',neq('c'))).
> select('d').groupCount()
> {code}
> So what's the problem? The problem is that where('d',neq('b')) is only going 
> to make sure that the current 'd' is not equal to the current 'b'. Not the 
> aggregate of all b's. How do we solve this? Here is how we would "manually" 
> solve it using Kuppitz' latest idea of adding a clear()-step, where 
> clear('x') => sideEffect{it.sideEffects('x').clear()}
> {code}
> g.V(1).match('a',
> as('a').clear('{b}').out('likes').aggregate('{b}').as('b'),
> as('b').in('likes').as('c'),
> as('c').out('likes').as('d'),
> where('d',not(within('{b}'))),
> where('a',neq('c'))).
> select('d').groupCount()
> {code}
> However, suppose that we make "{ }" (set) and "[ ]" (list) special label 
> characters whereby the above is compiled to from the following:
> {code}
> g.V(1).match('a',
> as('a').out('likes').as('{b}'),
> as('b').in('likes').as('c'),
> as('c').out('likes').as('d'),
> where('d',not(within('{b}'))),
> where('a',neq('c'))).
> select('d').groupCount()
> {code}
> In essence, if an end variable is labeled with "{ }" that means aggregate to 
> set ("[ ]" could mean aggregate to list). The variable name inside the "{ }" 
> is then the "drain" of the CollectingBarrierStep -- i.e., the single object 
> emission post aggregation. Next, the as("{b}") syntax need not be limited to 
> match() where, in fact, the first query of this email could be written as:
> {code}
> g.V(1).as('a').out('likes').as('{x}').
> in('likes').where(neq('a')).
> out('likes').where(not(within('{x}')).
> groupCount()
> {code}
> Where does the clear() go in the above? It goes after the first StartStep 
> encountered moving "left." Thus, the previous compiles to the following:
> {code}
> g.V(1).as('a').clear('{x}').out('likes').aggregate('{x}').as('x')
> in('likes').where(neq('a')).
> out('likes').where(not(within('{x}')).
> groupCount()
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1687) Record metrics around how long it gremlin script executions sit in executor queue waiting to be executed.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1687:

Fix Version/s: (was: 3.2.7)

> Record metrics around how long it gremlin script executions sit in executor 
> queue waiting to be executed.
> -
>
> Key: TINKERPOP-1687
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1687
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.4
>Reporter: David Pitera
>Priority: Minor
>  Labels: breaking
>
> The issue will be breaking because I will be moving the MetricManager into 
> the gremlin-core project from the gremlin-server project for easier use 
> across the project. Therefore whoever is using the MetricManager will need to 
> update their location from where they grab it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-819) Mapping Cardinality Interface

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-819:
---
Fix Version/s: (was: 3.2.7)

> Mapping Cardinality Interface
> -
>
> Key: TINKERPOP-819
> URL: https://issues.apache.org/jira/browse/TINKERPOP-819
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>Priority: Minor
>  Labels: breaking
>
> I think it would be handy (for some {{sack()}} work I'm doing on 
> merging/splitting sacks), but also in general as I've wanted this before 
> (can't remember why). I think we should add the following interfaces.
> {code}
> ManyToOneMapping (e.g. reducing barriers)
> OneToManyMapping (e.g. flatmap)
> OneToOneMapping (e.g. map, sideeffects)
> OneToOneOrNoneMapping (e.g. filter)
> {code}
> We can just rely on {{instanceof FlatMapStep}} or {{instanceof MapStep}} as 
> there are steps that are "map steps" but don't extend {{MapStep}}, but 
> instead {{AbstractStep}}. Either we make it so that all steps MUST extend 
> from {{FlatMapStep}}, {{MapStep}}, etc. or we can add the above interfaces.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-669) Consider Required TraversalStrategies

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-669:
---
Fix Version/s: (was: 3.2.7)

> Consider Required TraversalStrategies
> -
>
> Key: TINKERPOP-669
> URL: https://issues.apache.org/jira/browse/TINKERPOP-669
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> As we now execute the Gremln process suite with and without strategies 
> applied, it became apparent that some strategies are simply "required".  See:
> https://github.com/apache/incubator-tinkerpop/blob/0d239c05638269e6cd5c7af7bd3c61a50627d0bc/tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/process/TinkerGraphNoStrategyComputerProvider.java#L41-L46
> https://github.com/apache/incubator-tinkerpop/blob/0d239c05638269e6cd5c7af7bd3c61a50627d0bc/tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/process/TinkerGraphNoStrategyProvider.java#L42
> Not sure what this means in the grand scheme of things. A few things that 
> feel weird or require more thought:
> 1. Kinda weird that a {{Traversal}} requires any strategies at all to execute.
> 2. Kinda weird that a {{Step}} should know anything about strategies as is 
> the case with {{ConjunctionStrategy}} for example.
> 3. If required strategies are expected then should those required strategies 
> be somewhere more prominently maintained/documented/etc than just being 
> relegated to the test suite
> Not sure anything really needs to change here, just wanted to create an issue 
> for future thought.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1757) GiraphGraphComputer does not start Zookeeper in local mode

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1757:

Fix Version/s: (was: 3.3.1)
   (was: 3.2.7)

> GiraphGraphComputer does not start Zookeeper in local mode
> --
>
> Key: TINKERPOP-1757
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1757
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.3.0, 3.2.6
> Environment: gremlin-console in Ubuntu with Oracle java 8
>Reporter: Marc de Lignie
>Priority: Trivial
>
> As discussed in 
> [https://groups.google.com/forum/#!topic/gremlin-users/Ztbr_uJhoxY] running 
> GiraphGraphComputer in local mode (without an external or pseudo hadoop 
> cluster) requires the following configured properties (add section local to 
> the hadoop properties file):
> {code:java}
> gremlin.hadoop.inputLocation=data/tinkerpop-modern.kryo
> giraph.minWorkers=1
> giraph.maxWorkers=1
> giraph.SplitMasterWorker=false
> mapreduce.job.maps=4
> mapreduce.job.reduces=2
> {code}
> The real problem is that GiraphGraphComputer does not manage to start its 
> Zookeeper service because it gets relative classpath items from somewhere 
> (gremlin-console provides the acual shell command used to attempt starting 
> Zookeeper in its logging).
> Current workaround is to start gremlin-console as follows:
> {code:java}
> export CLASSPATH=$PWD/lib/*
> bin/gremlin.sh
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1129) Make StarGraphGraphSONSerializer and connect it up with GraphFilter and GraphSONInputFormat

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1129:

Fix Version/s: (was: 3.2.7)

> Make StarGraphGraphSONSerializer and connect it up with GraphFilter and 
> GraphSONInputFormat
> ---
>
> Key: TINKERPOP-1129
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1129
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, io
>Affects Versions: 3.2.5
>Reporter: Marko A. Rodriguez
>
> Currently, only {{ScriptInputFormat}} and {{GryoInputFormat}} are able to 
> leverage {{GraphFilter}} "close to the metal." We should do the same for 
> {{GraphSONInputFormat}} via {{StarGraphGraphSONSerializer}}. It shouldn't be 
> that hard, just need to do it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1711) map(union(fold())) bug

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1711:

Fix Version/s: (was: 3.2.7)

> map(union(fold())) bug
> --
>
> Key: TINKERPOP-1711
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1711
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.5
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
>
> Actual:
> {code:java}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().valueMap()
> ==>[name:[marko],age:[29]]
> ==>[name:[vadas],age:[27]]
> ==>[name:[lop],lang:[java]]
> ==>[name:[josh],age:[32]]
> ==>[name:[ripple],lang:[java]]
> ==>[name:[peter],age:[35]]
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[[],vadas]
> ==>[lop,[java]]
> ==>[[],josh]
> ==>[ripple,[java]]
> ==>[[],peter]
> {code}
> Expected:
> {code:java}
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[vadas,[]]
> ==>[lop,[java]]
> ==>[josh,[]]
> ==>[ripple,[java]]
> ==>[peter,[]]
> {code}
> List reference:  
> https://groups.google.com/forum/#!topic/gremlin-users/L_fESS6ta0A



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-963) SubgraphTraversalAnalyzer to determine what is really required from a traversal.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-963:
---
Fix Version/s: (was: 3.2.7)

> SubgraphTraversalAnalyzer to determine what is really required from a 
> traversal.
> 
>
> Key: TINKERPOP-963
> URL: https://issues.apache.org/jira/browse/TINKERPOP-963
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> This idea is dependent on the work in TINKERPOP3-962 being complete.
> The idea is that there should be a {{SubgraphTraversalAnalyzer}}-type step 
> that for a {{traversal}} returns a 
> {{Pair,Traversal>}} that defines two 
> "filters" that contain the subgraph that the traversal will execute in.
> For instance.
> {code}
> g.V().hasLabel("person").out("pets").hasLabel("dog")
> {code}
> {{SubgraphTraversalAnalyzer}} would return
> {code}
> Pair.with(
>   hasLabel("person","dog"),
>   hasLabel("pets"))
> {code}
> The difficulty with this ticket is that TinkerPop does NOT make any 
> assumptions about a schema. For instance, if the user did this:
> {code}
> g.V().hasLabel("person").out("pets")
> {code}
> Then the best we could return is:
> {code}
> Pair.with(
>   identity(),
>   hasLabel("pets"))
> {code}
> cc/ [~mbroecheler]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1717) Update name and link of DynamoDB storage backend in landing page

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1717:

Fix Version/s: (was: 3.3.1)

> Update name and link of DynamoDB storage backend in landing page
> 
>
> Key: TINKERPOP-1717
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1717
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.3
>Reporter: Alexander Patrikalakis
>Priority: Minor
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Amazon have released DynamoDB storage backends compatible with JG 0.1.0 and 
> 0.1.1:
> https://mvnrepository.com/artifact/com.amazonaws/dynamodb-janusgraph-storage-backend/1.0.0
> https://mvnrepository.com/artifact/com.amazonaws/dynamodb-janusgraph-storage-backend/1.1.0
> Also, we have renamed the repository on GitHub to 
> dynamodb-janusgraph-storage-backend for git history continuity. So, can we 
> update the names and links on the landing page? Also minor, I would like to 
> update the capitalization of "storage backend" -> "Storage Backend"
> Before:
> [Titan (Amazon)](https://github.com/awslabs/dynamodb-titan-storage-backend/)  
> - The Amazon DynamoDB storage backend for Titan.
> After:
> [JanusGraph 
> (Amazon)](https://github.com/awslabs/dynamodb-janusgraph-storage-backend/)  - 
> The Amazon DynamoDB Storage Backend for JanusGraph.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1187) Create a GraphComputer Tutorial

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1187:

Fix Version/s: (was: 3.2.7)

> Create a GraphComputer Tutorial
> ---
>
> Key: TINKERPOP-1187
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1187
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> We should create a GraphComputer tutorial that discusses:
> 1. GraphComputer, Memory, and VertexPrograms.
> 2. Explains how Traversals are compiled to TraversalVertexPrograms.
> 3. The mechanics of a TraversalVertexProgram.
> 4. How to write your own VertexProgram.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-967) Support nested-repeat() structures

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-967:
---
Fix Version/s: (was: 3.2.7)

> Support nested-repeat() structures
> --
>
> Key: TINKERPOP-967
> URL: https://issues.apache.org/jira/browse/TINKERPOP-967
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> All the internal plumbing is staged for this to happen, we just haven't gone 
> all the way. In short, a {{NESTED_LOOP}} traverser has an internal 
> {{loopStack}} where {{repeat(repeat())}} will have a {{loopStack}} of two. 
> The {{it.loops()}} checks of the internal repeat will always check the top of 
> the stack and when its done repeating will delete its counter off the top of 
> the stack.
> [~dkuppitz]'s work on {{LoopStep}} will be backwards compatible. In 
> {{RepeatStep}} we will support:
> {code}
> repeat('a',out('knows').repeat('b',out('parent')))
> {code}
> and thus, things like {{loops('a')}} as well as {{times('a',2)}}. Note that 
> naming the loop stack will be a super rare case as most people will just 
> assume standard nested looping semantics with a push/pop stack.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1141) HadoopRemoteAcceptor is overly complicated. Simplify with ComputerResult as a SideEffect in OLAP Traversal.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1141:

Fix Version/s: (was: 3.2.7)

> HadoopRemoteAcceptor is overly complicated. Simplify with ComputerResult as a 
> SideEffect in OLAP Traversal.
> ---
>
> Key: TINKERPOP-1141
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1141
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>
> {{HadoopRemoteAcceptor}} is overly complicated. I think that instead of 
> making {{ComputerResult}} a value in the Console, we should just add 
> {{ComputerResult}} to the OLAP {{Traversal}}.
> {code}
> t = g.V().out().count()
> result = t.getSideEffects().get('~computerResult')
> {code}
> For most people, they will never use this as computer result memory is 
> already in the sideEffects. However, {{ComputerResult}} also has other 
> information like iteration, runtime, and graph.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1074) More contractual testing/specifications around Persist and ResultGraph.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1074:

Fix Version/s: (was: 3.2.7)

> More contractual testing/specifications around Persist and ResultGraph.
> ---
>
> Key: TINKERPOP-1074
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1074
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>
> A {{ComputerResult}} references two objects: a graph and a memory. The graph 
> is the resultant computed graph and the memory contains all the sideEffect 
> data from the computation (if any).
> Right now, we have the following {{Persist}} options: {{NOTHING}}, 
> {{VERTEX_PROPERTIES}}, {{EDGES}}. We also have the following {{ResultGraph}} 
> options: {{ORIGINAL}}, {{NEW}}.
> * NOTHING + ORIGINAL = ComputerResult contains original graph reference.
> * NOTHING + NEW = ?? No test to force what this means! Should be 
> {{EmptyGraph.instance()}}.
> * VERTEX_PROPERTIES + ORIGINAL = ComputerResult contains original graph, but 
> the computed vertex properties have been "saved" to it. (no contractual test 
> cases here either!)
> * VERTEX_PROPERTIES + NEW = ComputerResult contains new graph with only 
> vertices and their properties.
> * EDGES + NEW = ComputerResult contains new graph with vertices, edges, and 
> their properties.
> * EDGES + ORIGINAL = ComputerResult contains original graph, but the computed 
> vertex properties and edges have been "saved" to it. (no contractual test 
> cases here either!)
> {{TinkerGraphComputer}} is the only system that supports all the above 
> configuration combinations. Add test cases to {{GraphComputerTest}} that 
> verify the behavior of all combinations.
> HOWEVER  -- should we really respect ORIGINAL+PERSIST? Most providers 
> will use {{BulkLoaderVertexProgram}} to write the computed graph back to the 
> original graph. If there are TWO ways of doing this, this seems bad? In fact, 
> the way that TinkerGraphComputer writes the computed graph back to the 
> original graph is nearly identical to how it BulkLoaderVertexProgram works. 
> Thus, I'm wondering if we simply get rid the concept of {{ResultGraph}} and 
> ONLY have {{Persist}}.
> * Persist.NOTHING: Returns the original graph in {{ComputerResult}}.
> * Persist.VERTEX_PROPERTIES: Returns a new graph with only vertices and 
> properties.
> * Persist.EDGES: Returns a new graph with vertices, edges, and their 
> properties.
> For in-memory graphs like {{TinkerGraph}}, "new graph" can mean the original 
> graph with the {{GraphView}} overlay. Thus, its not really a full copy of the 
> original graph. Moreover, Persist.NOTHING just garbage collects the GraphView 
> and thus, the original graph.
> --
> Next, what does {{Persist}} mean for memory? Remember, {{ComputerResult}} 
> also has a reference to sideEffect memory. What if you want to run a job, NOT 
> persist the graph, but persist the memory only. I think we should ALWAYS 
> assume memory persistence. For TinkerGraph, that means the the 
> ComputerResult.memory() has a HashMap of memory values. For Giraph/Spark, 
> that means that the {{Storage}} will always have resultant sideEffect data in 
> the output directory even if there is no graph.
> * {{NOTHING}}: persist memory and return the original graph.
> * {{VERTEX_PROPERTIES}}: persist memory and return new graph of just vertex 
> properties.
> * {{EDGES}}: persist memory and return new graph of vertex properties, and 
> edges.
> Decisions, decisions, decisions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1098) Local Filters

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1098:

Fix Version/s: (was: 3.2.7)

> Local Filters
> -
>
> Key: TINKERPOP-1098
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1098
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Daniel Kuppitz
>
> We should provide local filter steps. Currently, if you want to filter 
> elements from paths or lists (or maps?), you have to do 
> {{unfold().filter().fold()}}.
> Not sure if that only affects {{filter()}}, or also {{has()}}, {{hasNot()}}, 
> {{where()}}, ...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-878) Refactor Gremlin Server integration tests to be Client parameterized

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-878:
---
Fix Version/s: (was: 3.3.1)

> Refactor Gremlin Server integration tests to be Client parameterized
> 
>
> Key: TINKERPOP-878
> URL: https://issues.apache.org/jira/browse/TINKERPOP-878
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>
> Would be nice if Gremlin Server integration tests (at least the ones that 
> make sense anyway) were executed over both Websockets and NIO to generally 
> validate their capabilities.  We could likely create parameterized tests to 
> do this.  That would also pave the way for easily testing new transports if 
> they are ever added.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-620) Commutative Step Marker interface

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-620:
---
Fix Version/s: (was: 3.2.7)

> Commutative Step Marker interface
> -
>
> Key: TINKERPOP-620
> URL: https://issues.apache.org/jira/browse/TINKERPOP-620
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Matthias Broecheler
>
> Some steps can be reordered, i.e. they are commutative. For instance, 
> has-steps can be reordered without affecting the pipeline. When writing a 
> query optimizer I am often in a situation where I can only optimize a subset 
> of the supported steps and I might want to reorder them so that I can group 
> all the optimizable steps together. Currently, I have to manually identify 
> the commutative steps for that. It would be much nicer if TinkerPop could 
> have a "Commutative" marker interface for that and use it consistently.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1535) Bump to support Giraph 1.2.0.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1535:

Fix Version/s: (was: 3.3.1)

> Bump to support Giraph 1.2.0.
> -
>
> Key: TINKERPOP-1535
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1535
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-940) Convert LocalTraversals to MatchSteps in OLAP and Solve the StarGraph Problem

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-940:
---
Fix Version/s: (was: 3.2.7)

> Convert LocalTraversals to MatchSteps in OLAP and Solve the StarGraph Problem
> -
>
> Key: TINKERPOP-940
> URL: https://issues.apache.org/jira/browse/TINKERPOP-940
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> This fails in OLAP.
> {code}
> g.V().match(
>   as('a').out('sungBy').as('b'),
>   as('a').out('writtenBy').as('b')).
> select('a','b').by('name')
> {code}
> However, this passes:
> {code}
> g.V().match(
>   as('a').out('sungBy').as('b'),
>   as('a').out('writtenBy').as('b'),
>   as('a').values('name').as('c'),
>   as('b').values('name').as('d')).
> select('c','d')
> {code}
> Can all "local star graph" OLAP problems be strategized into MatchSteps? It 
> would be a decoration strategy of some sort [~dkuppitz]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-882) Develop a less error prone way for rewriting strategies

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-882:
---
Fix Version/s: (was: 3.2.7)

> Develop a less error prone way for rewriting strategies
> ---
>
> Key: TINKERPOP-882
> URL: https://issues.apache.org/jira/browse/TINKERPOP-882
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>
> When someone writes a {{TraversalStrategy}} it is of the nature:
> {code}
> if(step instanceof SelectStep && ((SelectStep)step).getLocalChildren().size() 
> > 1) {
>   TraversalHelper.insertStep(new IdentityStep(), step, traversal);
> }
> {code}
> It can start to get hairy looking fast. It would be great if we could study 
> the strategies we have thus far and see if there are patterns we can extract 
> encapsulate such behaviors in new methods in {{TraversalHelper}}. I don't 
> have any good ideas on how to do this, but I think we need it. My only 
> thought was a "regular expression" language for our traversals so we can 
> pattern match ON the traversal. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-831) How should OLAP treat Collection objects? No contract is specified.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-831:
---
Fix Version/s: (was: 3.2.7)

> How should OLAP treat Collection objects? No contract is specified.
> 
>
> Key: TINKERPOP-831
> URL: https://issues.apache.org/jira/browse/TINKERPOP-831
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>  Labels: breaking
>
> Assume the following OLAP query:
> {code}
> g.V.group.by(label).by().by(order(local).by('name'))
> {code}
> The {{Map}} that is processed by {{GroupMapReduce}} 
> doesn't have "real vertices." For TinkerGraph/Spark/Giraph, we use 
> {{DetachedVertices}}. However, we don't have a specification for forcing this 
> on vendors.  We need a contract so its not "who knows?! -- pura vida 
> -- namaste -- comme ci, comme ça"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-871) RuntimeStrategy as the general model for all such execution time rewrites/re-orders

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-871:
---
Fix Version/s: (was: 3.2.7)

> RuntimeStrategy as the general model for all such execution time 
> rewrites/re-orders
> ---
>
> Key: TINKERPOP-871
> URL: https://issues.apache.org/jira/browse/TINKERPOP-871
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>  Labels: breaking
>
> {{TraversalStrategies}} are used at compile time to translate a traversal 
> into a more optimal, graph system specific, or decorated traversal. These all 
> execute at compile time. However, we also have {{MatchAlgorithm}} which is 
> used by {{MatchStep}} to do runtime analysis and resort patterns accordingly. 
> I would like to make {{MatchAlgorithm}} implement {{RuntimeStrategy}} and 
> start to build out a collection of {{RuntimeStrategies}}. Where else could we 
> leverage runtime analysis:
> * {{OrStep}} and {{AndStep}} -- which pattern is filtering fastest? Do that 
> first.
> * {{MatchStep}} -- already using it with {{CountMatchAlgorithm}} and pattern 
> sorting.
> * ??? 
> ... can't think, there are probably more.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1343) A more efficient StarGraph serialization representation.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1343:

Fix Version/s: (was: 3.3.1)

> A more efficient StarGraph serialization representation.
> 
>
> Key: TINKERPOP-1343
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1343
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> {{StarGraph}} is used by the Hadoop {{GraphComputers}} and represents a 
> vertex, its properties, its incident edges, and their properties. In essence, 
> one "row of an adjacency list."
> Here are some ideas on how to make the next version of the serialization 
> format more efficient.
> 1. For all Element ids, we currently use {{kryo.readClassAndObject(...)}}. 
> This is bad because we have to write the class with each id. It would be 
> better if the {{StarGraph}} had metadata like {{vertexIdClass}}, 
> {{vertexPropertyIdClass}}, and {{edgeIdClass}}. Now for every vertex we are 
> serializing three class, but the benefit is that every id class is now known 
> and we can use {{kryo.readObject(..., xxxIdClass)}}.
> 2. Edges and VertexProperties are written out as {{[ edgeLabel[ edge[ id, 
> otherVertexId]\*]\*}} and {{[ propertyKey[ vertexProperty[ 
> id,propertyValue]\*]\*}}, respectively. This ensures we don't write so many 
> strings as all edges/vertex properties are grouped by label. However, we do 
> NOT do this for edge properties nor vertex property properties. We simply 
> write out the {{Map>}} which is 
> {{Map>}}. Since we have to choose 
> between grouping by edgeId or by propertyKey, we should keep it as it is, but 
> create a "meta map" that allows us to represent all property keys in a, e.g., 
> {{int}} space. Thus, {{Map>}} 
> where we also have a {{Map}} that is serialized 
> with the {{StarGraph}}.
> There are a few other tickets around optimizing {{StarGraph}} here:
> https://issues.apache.org/jira/browse/TINKERPOP-1128 (making {{GraphFilters}} 
> more efficient)
> https://issues.apache.org/jira/browse/TINKERPOP-1122 (pointless bits and 
> {{StarGraph}} should never auto-generate IDs as the ID space is distributed).
> https://issues.apache.org/jira/browse/TINKERPOP-1287 (related to heap usage 
> and clock cycles -- not serialization).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1346) Create custom ReferenceXXX GryoSerializers

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1346:

Fix Version/s: (was: 3.3.1)

> Create custom ReferenceXXX GryoSerializers
> --
>
> Key: TINKERPOP-1346
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1346
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, structure
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> Right now, to send a {{ReferenceEdge}} message, we serialize the form as:
> {code}
> KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] + 
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] + 
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
> {code}
> Assuming {{Long}} Element ids, the math says:
> {code}
> 48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8 
> bytes [long]) + 4 bytes + (4 bytes + 8 bytes [long])
> {code}
> We could get this smaller by not relying on Kryo's {{FieldSerializer}}.
> {code}
> KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] + 
> KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
> {code}
> The math says:
> {code}
> 36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] + 
> 8 bytes [long]
> {code}
> Similar techniques would apply to {{ReferenceVertexProperty}} and 
> {{ReferenceProperty}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1118) SparkGraphComputer should use StarGraph, not VertexWritable.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1118:

Fix Version/s: (was: 3.3.1)

> SparkGraphComputer should use StarGraph, not VertexWritable.
> 
>
> Key: TINKERPOP-1118
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1118
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> {{SparkGraphComputer}} input RDDs are typed as:
> {code}
> JavaPairRDD
> {code}
> The {{VertexWritable}} usage is a vestige from Hadoop and Giraph. In Spark, 
> we don't need to have this wrapper and thus, we can reduce the overhead (one 
> less object header) by making the input RDDs typed as:
> {code}
> JavaPairRDD
> {code}
> This would be a breaking change for graph providers that implement their own 
> {{InputRDD}} and {{OutputRDD}}, however, the fix is trivial. Instead of {{new 
> VertexWritable(vertex)}}, they would simply do {{StarGraph.of(vertex)}}. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1128) Change the Gryo serialization for StarGraph (Vertex, Properties, then Edges)

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1128:

Fix Version/s: (was: 3.3.1)

> Change the Gryo serialization for StarGraph (Vertex, Properties, then Edges)
> 
>
> Key: TINKERPOP-1128
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1128
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> Right now we serialize first the vertex, then its edges, then its properties. 
> We should do vertex, properties, edges. Why? If we know that the vertex is to 
> be filtered (which is an analysis of its label/id/properties), then we can 
> skip over analyzing its edges. Right now, we may do all this work 
> deserializing edges only to realize that the {{GraphFilter}} says that the 
> vertex is filtered. Dah, pointless clock cycles -- especially when edge sets 
> can be massive.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1515) One test suite to rule them all

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1515:

Fix Version/s: (was: 3.3.1)

> One test suite to rule them all
> ---
>
> Key: TINKERPOP-1515
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1515
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>  Labels: breaking
>
> Make an attempt at an uber test module that would collapse all provider 
> related tests into a single module. I say "attempt" as I'm not completely 
> aware of what kinds of dependency conflicts I'll see try to do this.  
> Consider TINKERPOP-1410 in doing this.
> Obviously this change would be breaking if modules are combined and package 
> renaming occurs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1344) ReferenceYYYXXX for better message passing

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1344:

Fix Version/s: (was: 3.3.1)

> ReferenceYYYXXX for better message passing
> --
>
> Key: TINKERPOP-1344
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1344
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>
> In https://issues.apache.org/jira/browse/TINKERPOP-1343, I was saying that it 
> would be nice to have the element id type be known so we can do 
> {{writeObject()}} as opposed to {{writeObjectAndClass()}}. I think we could 
> do some good with a hiearchy of classes like:
> {code}
> ReferenceIntVertex
> ReferenceLongVertex
> ReferenceVertex (Object -- what we have now)
> ReferenceUUIDVertex
> ...
> {code}
> ...likewise for Edge, VertexProperty...
> This will save us an extra 32-bits (4 byte int) on the serialization of 
> messages during OLAP message pass as that is all {{ReferenceXXX}} based.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1122) StarGraph has a Long nextId. That is pointless and a waste of 64-bits.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1122:

Fix Version/s: (was: 3.3.1)

> StarGraph has a Long nextId. That is pointless and a waste of 64-bits.
> --
>
> Key: TINKERPOP-1122
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1122
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, io, structure
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> {code}
> protected Long nextId = 0l;
> private Long nextId() {
> return this.nextId++;
> }
> {code}
> This makes no sense as then each StarGraph in the full Graph will have 
> similar ids! Moreover, what is referencing what when the adjacent vertices 
> are just arbitrary long ids?!!  We should require that StarGraph get provided 
> ids for vertices (and perhaps edges)... We ensure no inconsistencies and we 
> save 64-bits.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1768) Bump to Jackson 2.8.10

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1768.
---
Resolution: Done

> Bump to Jackson 2.8.10
> --
>
> Key: TINKERPOP-1768
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1768
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.7, 3.3.1
>
>
> Jackson 2.8.10 has some important bug fixes - hoping for a fix for 
> TINKERPOP-1509



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1326) Use KryoShim for serialization in VertexProgramHelper

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1326:

Fix Version/s: (was: 3.3.1)

> Use KryoShim for serialization in VertexProgramHelper
> -
>
> Key: TINKERPOP-1326
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1326
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, process, structure
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> At the next major release, we should swap out the Java serialization work in 
> {{VertexProgramHelper}} and instead, use the {{KryoShim}} work developed by 
> [~dalaro]. This means we need a {{KryoShimService}} in {{gremlin-core}}. I 
> say we remove the {{HadoopPoolsKryoShimService}} and go with a 
> {{GryoPoolKryoShimService}} that then Hadoop-based OLAP engines can use (as 
> well as engines like TinkerGraph).
> This would a a "minor breaking" change as I suspect no provider is that deep 
> into the serialization API of TinkerPop and the change would be a simple 
> "change X to Y" sort of change for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1567.
---
Resolution: Fixed

> GraphSON deserialization fails with within('a')
> ---
>
> Key: TINKERPOP-1567
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1567
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python, 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 
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:339)
> at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
> at 
> 

[jira] [Closed] (TINKERPOP-1576) gremlin-python calls non-existent methods

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1576.
---
Resolution: Fixed

> gremlin-python calls non-existent methods
> -
>
> Key: TINKERPOP-1576
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1576
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Florian Hockmann
>Assignee: Marko A. Rodriguez
>Priority: Trivial
> Fix For: 3.2.4
>
>
> The {{\_\_}} class calls two methods of the {{GraphTraversal}} class that are 
> not present in that class, namely: the constructor {{__()}} and {{start()}}
> {code}
> >>> __.__()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 401, in __
> return GraphTraversal(None, None, Bytecode()).__(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> {code}
> >>> __.start()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 623, in start
> return GraphTraversal(None, None, Bytecode()).start(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> This can be easily fixed by excluding those two methods in the 
> {{GraphTraversalSourceGenerator}}. I will create a pull request for that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1576) gremlin-python calls non-existent methods

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1576:
-

> gremlin-python calls non-existent methods
> -
>
> Key: TINKERPOP-1576
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1576
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Florian Hockmann
>Assignee: Marko A. Rodriguez
>Priority: Trivial
> Fix For: 3.2.4
>
>
> The {{\_\_}} class calls two methods of the {{GraphTraversal}} class that are 
> not present in that class, namely: the constructor {{__()}} and {{start()}}
> {code}
> >>> __.__()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 401, in __
> return GraphTraversal(None, None, Bytecode()).__(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> {code}
> >>> __.start()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 623, in start
> return GraphTraversal(None, None, Bytecode()).start(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> This can be easily fixed by excluding those two methods in the 
> {{GraphTraversalSourceGenerator}}. I will create a pull request for that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1635) gremlin-python: Duplicate serialization of element property in PropertySerializer

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1635:

Component/s: (was: language-variant)
 python

> gremlin-python: Duplicate serialization of element property in 
> PropertySerializer
> -
>
> Key: TINKERPOP-1635
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1635
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.0
>Reporter: Florian Hockmann
>Assignee: stephen mallette
>Priority: Trivial
> Fix For: 3.3.0
>
>
> The {{PropertySerializer}} in the current master branch of gremlin-python 
> serializes the element property twice:
> {code}
> elementDict = writer.toDict(property.element)
> #...
> "element": writer.toDict(elementDict)
> {code}
> This isn't a problem when the element only contains simple types like strings 
> that aren't serialized by adding a type attribute (like in the unit test for 
> this component). However, all other types like integers for example are 
> serialized two times. So an integer will be serialized to:
> {code}
> {"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}}
> {code}
> Full example:
> {code}
> >>> p = Property("aKey","aValue", Edge(123, Vertex(1), "edgeLabel", 
> >>> Vertex(2)))
> >>> writer.writeObject(p)
> '{"@type":"g:Property","@value":{"value":"aValue","key":"aKey","element":{"@type":"g:Edge","@value":{"inV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":2}},"id":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":123}},"outV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}},"label":"edgeLabel"'
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1635) gremlin-python: Duplicate serialization of element property in PropertySerializer

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1635:
-

> gremlin-python: Duplicate serialization of element property in 
> PropertySerializer
> -
>
> Key: TINKERPOP-1635
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1635
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.0
>Reporter: Florian Hockmann
>Assignee: stephen mallette
>Priority: Trivial
> Fix For: 3.3.0
>
>
> The {{PropertySerializer}} in the current master branch of gremlin-python 
> serializes the element property twice:
> {code}
> elementDict = writer.toDict(property.element)
> #...
> "element": writer.toDict(elementDict)
> {code}
> This isn't a problem when the element only contains simple types like strings 
> that aren't serialized by adding a type attribute (like in the unit test for 
> this component). However, all other types like integers for example are 
> serialized two times. So an integer will be serialized to:
> {code}
> {"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}}
> {code}
> Full example:
> {code}
> >>> p = Property("aKey","aValue", Edge(123, Vertex(1), "edgeLabel", 
> >>> Vertex(2)))
> >>> writer.writeObject(p)
> '{"@type":"g:Property","@value":{"value":"aValue","key":"aKey","element":{"@type":"g:Edge","@value":{"inV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":2}},"id":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":123}},"outV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}},"label":"edgeLabel"'
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1576) gremlin-python calls non-existent methods

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1576:

Component/s: (was: language-variant)
 python

> gremlin-python calls non-existent methods
> -
>
> Key: TINKERPOP-1576
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1576
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Florian Hockmann
>Assignee: Marko A. Rodriguez
>Priority: Trivial
> Fix For: 3.2.4
>
>
> The {{\_\_}} class calls two methods of the {{GraphTraversal}} class that are 
> not present in that class, namely: the constructor {{__()}} and {{start()}}
> {code}
> >>> __.__()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 401, in __
> return GraphTraversal(None, None, Bytecode()).__(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> {code}
> >>> __.start()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program 
> Files\Python35\Lib\site-packages\gremlin_python\process\graph_traversal.py", 
> line 623, in start
> return GraphTraversal(None, None, Bytecode()).start(*args)
> TypeError: 'GraphTraversal' object is not callable
> {code}
> This can be easily fixed by excluding those two methods in the 
> {{GraphTraversalSourceGenerator}}. I will create a pull request for that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1635) gremlin-python: Duplicate serialization of element property in PropertySerializer

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1635.
---
Resolution: Fixed

> gremlin-python: Duplicate serialization of element property in 
> PropertySerializer
> -
>
> Key: TINKERPOP-1635
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1635
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.0
>Reporter: Florian Hockmann
>Assignee: stephen mallette
>Priority: Trivial
> Fix For: 3.3.0
>
>
> The {{PropertySerializer}} in the current master branch of gremlin-python 
> serializes the element property twice:
> {code}
> elementDict = writer.toDict(property.element)
> #...
> "element": writer.toDict(elementDict)
> {code}
> This isn't a problem when the element only contains simple types like strings 
> that aren't serialized by adding a type attribute (like in the unit test for 
> this component). However, all other types like integers for example are 
> serialized two times. So an integer will be serialized to:
> {code}
> {"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}}
> {code}
> Full example:
> {code}
> >>> p = Property("aKey","aValue", Edge(123, Vertex(1), "edgeLabel", 
> >>> Vertex(2)))
> >>> writer.writeObject(p)
> '{"@type":"g:Property","@value":{"value":"aValue","key":"aKey","element":{"@type":"g:Edge","@value":{"inV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":2}},"id":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":123}},"outV":{"@type":"g:Int32","@value":{"@type":"g:Int32","@value":1}},"label":"edgeLabel"'
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1567:
-

> GraphSON deserialization fails with within('a')
> ---
>
> Key: TINKERPOP-1567
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1567
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python, 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 
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:339)
> at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
> at 
> 

[jira] [Closed] (TINKERPOP-1665) Remove unittest from Gremlin-Python tests

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1665.
---
Resolution: Fixed

> Remove unittest from Gremlin-Python tests
> -
>
> Key: TINKERPOP-1665
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1665
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.4
>Reporter: David M. Brown
>Assignee: David M. Brown
>Priority: Minor
> Fix For: 3.2.5
>
>
> Since we are using Pytest, it is isn't necessary to use Python's unittest 
> module



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1567:

Component/s: (was: language-variant)
 python

> GraphSON deserialization fails with within('a')
> ---
>
> Key: TINKERPOP-1567
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1567
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python, 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 
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:339)
> at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
> at 
> 

[jira] [Updated] (TINKERPOP-1618) Remove groovy dependency from gremlin-python

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1618:

Component/s: (was: language-variant)
 python

> Remove groovy dependency from gremlin-python
> 
>
> Key: TINKERPOP-1618
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1618
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.5
>
>
> {{gremlin-python}} currently depends on groovy for its code generation needs. 
> This dependency could probably be removed in favor of the scripts being 
> executed as part of the gmavenplus plugin directly in the pom.xml. In this 
> way the gremlin-python jar would no longer have a dependency on groovy.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1618) Remove groovy dependency from gremlin-python

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1618.
---
Resolution: Done

> Remove groovy dependency from gremlin-python
> 
>
> Key: TINKERPOP-1618
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1618
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.5
>
>
> {{gremlin-python}} currently depends on groovy for its code generation needs. 
> This dependency could probably be removed in favor of the scripts being 
> executed as part of the gmavenplus plugin directly in the pom.xml. In this 
> way the gremlin-python jar would no longer have a dependency on groovy.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1665) Remove unittest from Gremlin-Python tests

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1665:
-

> Remove unittest from Gremlin-Python tests
> -
>
> Key: TINKERPOP-1665
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1665
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.4
>Reporter: David M. Brown
>Assignee: David M. Brown
>Priority: Minor
> Fix For: 3.2.5
>
>
> Since we are using Pytest, it is isn't necessary to use Python's unittest 
> module



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1665) Remove unittest from Gremlin-Python tests

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1665:

Component/s: (was: language-variant)
 python

> Remove unittest from Gremlin-Python tests
> -
>
> Key: TINKERPOP-1665
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1665
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.4
>Reporter: David M. Brown
>Assignee: David M. Brown
>Priority: Minor
> Fix For: 3.2.5
>
>
> Since we are using Pytest, it is isn't necessary to use Python's unittest 
> module



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1523) A means of clarifying an explicit type in DSL with language variants

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1523:
-

> A means of clarifying an explicit type in DSL with language variants
> 
>
> Key: TINKERPOP-1523
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1523
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, process
>Affects Versions: 3.2.3
>Reporter: Andy Tolbert
>Priority: Minor
>
> Depending on the host programming language, it is not possible/clear when 
> implementing a gremlin language variant how a user could communicate a given 
> type that is not supported in their language.
> For example, in python and javascript, there isn't a way to differentiate 
> between a float and a double, yet {{Double}} and {{Float}} are valid types in 
> gremlin language variants.
> In the case of deserializing, it is pretty clear what needs to be done, the 
> code needs to coerce the types into a type that host language can handle, as 
> specified in the [GLV 
> docs|https://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/]:
> {quote}
> Language drivers are responsible for submitting Gremlin traversals to a 
> TinkerPop-enabled graph system and returning results to the developer that 
> are within the developer’s language’s type system. For instance, resultant 
> doubles should be coerced to floats in Python.
> {quote}
> What isn't clear to me is what to do in the serialization case.  As the type 
> is optional, you could simply provide the numerical value and leave it to the 
> backend implementation to handle it appropriately, but the type can cause the 
> backend to handle things differently.   For example, if the backend generates 
> a schema on the fly, it might decide that a value of 2 is an {{Int32}} when 
> maybe what the user wanted was a {{Int16}} for example. You could argue 
> that you could predefine the schema to avoid this, but lets ignore that for a 
> moment. 
> I think it would be nice is if there was some way in the DSL for the user to 
> communicate the underlying type that should be used in the traversal, i.e.:
> {code:javascript}
> g.E().has("weight", asFloat(0.2))
> {code}
> {{asFloat}} and other {{asXXX}} methods could be a way for a host environment 
> without an adequate type system to communicate the underlying type.  Also, a 
> {{as(typename)}} method could be useful for communicating arbitrary types 
> that are maybe implementation specific.
> Any implementation could provide this functionality themselves, but I'm 
> wondering if it would be useful to make this part of the specification of 
> things a GLV implementation could provide, that way there is a somewhat 
> standard way of communicating types in absence of types in the host language.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1425) Use trailing underscores in gremlin-python

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1425:

Component/s: (was: language-variant)
 python

> Use trailing underscores in gremlin-python
> --
>
> Key: TINKERPOP-1425
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1425
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.2
>
>
> As per discussion on TINKERPOP-1278 it seems more pythonesque to use trailing 
> underscores rather than leading.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1523) A means of clarifying an explicit type in DSL with language variants

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1523.
---
Resolution: Won't Do

> A means of clarifying an explicit type in DSL with language variants
> 
>
> Key: TINKERPOP-1523
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1523
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, process
>Affects Versions: 3.2.3
>Reporter: Andy Tolbert
>Priority: Minor
>
> Depending on the host programming language, it is not possible/clear when 
> implementing a gremlin language variant how a user could communicate a given 
> type that is not supported in their language.
> For example, in python and javascript, there isn't a way to differentiate 
> between a float and a double, yet {{Double}} and {{Float}} are valid types in 
> gremlin language variants.
> In the case of deserializing, it is pretty clear what needs to be done, the 
> code needs to coerce the types into a type that host language can handle, as 
> specified in the [GLV 
> docs|https://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/]:
> {quote}
> Language drivers are responsible for submitting Gremlin traversals to a 
> TinkerPop-enabled graph system and returning results to the developer that 
> are within the developer’s language’s type system. For instance, resultant 
> doubles should be coerced to floats in Python.
> {quote}
> What isn't clear to me is what to do in the serialization case.  As the type 
> is optional, you could simply provide the numerical value and leave it to the 
> backend implementation to handle it appropriately, but the type can cause the 
> backend to handle things differently.   For example, if the backend generates 
> a schema on the fly, it might decide that a value of 2 is an {{Int32}} when 
> maybe what the user wanted was a {{Int16}} for example. You could argue 
> that you could predefine the schema to avoid this, but lets ignore that for a 
> moment. 
> I think it would be nice is if there was some way in the DSL for the user to 
> communicate the underlying type that should be used in the traversal, i.e.:
> {code:javascript}
> g.E().has("weight", asFloat(0.2))
> {code}
> {{asFloat}} and other {{asXXX}} methods could be a way for a host environment 
> without an adequate type system to communicate the underlying type.  Also, a 
> {{as(typename)}} method could be useful for communicating arbitrary types 
> that are maybe implementation specific.
> Any implementation could provide this functionality themselves, but I'm 
> wondering if it would be useful to make this part of the specification of 
> things a GLV implementation could provide, that way there is a somewhat 
> standard way of communicating types in absence of types in the host language.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1523) A means of clarifying an explicit type in DSL with language variants

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1523:

Component/s: (was: language-variant)
 process
 io

> A means of clarifying an explicit type in DSL with language variants
> 
>
> Key: TINKERPOP-1523
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1523
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, process
>Affects Versions: 3.2.3
>Reporter: Andy Tolbert
>Priority: Minor
>
> Depending on the host programming language, it is not possible/clear when 
> implementing a gremlin language variant how a user could communicate a given 
> type that is not supported in their language.
> For example, in python and javascript, there isn't a way to differentiate 
> between a float and a double, yet {{Double}} and {{Float}} are valid types in 
> gremlin language variants.
> In the case of deserializing, it is pretty clear what needs to be done, the 
> code needs to coerce the types into a type that host language can handle, as 
> specified in the [GLV 
> docs|https://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/]:
> {quote}
> Language drivers are responsible for submitting Gremlin traversals to a 
> TinkerPop-enabled graph system and returning results to the developer that 
> are within the developer’s language’s type system. For instance, resultant 
> doubles should be coerced to floats in Python.
> {quote}
> What isn't clear to me is what to do in the serialization case.  As the type 
> is optional, you could simply provide the numerical value and leave it to the 
> backend implementation to handle it appropriately, but the type can cause the 
> backend to handle things differently.   For example, if the backend generates 
> a schema on the fly, it might decide that a value of 2 is an {{Int32}} when 
> maybe what the user wanted was a {{Int16}} for example. You could argue 
> that you could predefine the schema to avoid this, but lets ignore that for a 
> moment. 
> I think it would be nice is if there was some way in the DSL for the user to 
> communicate the underlying type that should be used in the traversal, i.e.:
> {code:javascript}
> g.E().has("weight", asFloat(0.2))
> {code}
> {{asFloat}} and other {{asXXX}} methods could be a way for a host environment 
> without an adequate type system to communicate the underlying type.  Also, a 
> {{as(typename)}} method could be useful for communicating arbitrary types 
> that are maybe implementation specific.
> Any implementation could provide this functionality themselves, but I'm 
> wondering if it would be useful to make this part of the specification of 
> things a GLV implementation could provide, that way there is a somewhat 
> standard way of communicating types in absence of types in the host language.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1425) Use trailing underscores in gremlin-python

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1425.
---
Resolution: Fixed

> Use trailing underscores in gremlin-python
> --
>
> Key: TINKERPOP-1425
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1425
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.2
>
>
> As per discussion on TINKERPOP-1278 it seems more pythonesque to use trailing 
> underscores rather than leading.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1278:
-

> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.2
>
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1449) Streamline gremlin-python build

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1449:
-

> Streamline gremlin-python build
> ---
>
> Key: TINKERPOP-1449
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1449
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release, python
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.3
>
>
> Seems like there is a bit of extra processing and stuff going on in the 
> gremlin-python build automation. Most notably:
> 1. there are two executions of jython when only one seems necessary
> 2. doing a -DskipTests skips more stuff than it probably should - would be 
> nice to skip testing and still get valid packaging. not sure how probably 
> this will be
> 3. there's a number of seemingly superfluous settings that i don't believe 
> serve any purpose and should be removed. validate that that they can be 
> removed and if not, figure out what they are so the don't seem so superfluous 
> any more.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1448) gremlin-python should be Python 2/3 compatible

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1448.
---
Resolution: Fixed

> gremlin-python should be Python 2/3 compatible
> --
>
> Key: TINKERPOP-1448
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1448
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.2
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.2.3
>
>
> As discussed here, it is simple to maintain Python 2/3 compatibility for 
> gremlin-python GLV: 
> https://lists.apache.org/thread.html/263739a38133be620dd32640fe997388e76b20379a3dae44b10d4442@%3Cdev.tinkerpop.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1425) Use trailing underscores in gremlin-python

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1425:
-

> Use trailing underscores in gremlin-python
> --
>
> Key: TINKERPOP-1425
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1425
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.2
>
>
> As per discussion on TINKERPOP-1278 it seems more pythonesque to use trailing 
> underscores rather than leading.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1448) gremlin-python should be Python 2/3 compatible

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1448:

Component/s: (was: language-variant)
 python

> gremlin-python should be Python 2/3 compatible
> --
>
> Key: TINKERPOP-1448
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1448
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.2
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.2.3
>
>
> As discussed here, it is simple to maintain Python 2/3 compatibility for 
> gremlin-python GLV: 
> https://lists.apache.org/thread.html/263739a38133be620dd32640fe997388e76b20379a3dae44b10d4442@%3Cdev.tinkerpop.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1278:

Component/s: (was: language-variant)
 python

> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.2
>
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1278.
---
Resolution: Fixed

> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.2
>
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1449) Streamline gremlin-python build

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1449:

Component/s: (was: language-variant)
 python

> Streamline gremlin-python build
> ---
>
> Key: TINKERPOP-1449
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1449
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release, python
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.3
>
>
> Seems like there is a bit of extra processing and stuff going on in the 
> gremlin-python build automation. Most notably:
> 1. there are two executions of jython when only one seems necessary
> 2. doing a -DskipTests skips more stuff than it probably should - would be 
> nice to skip testing and still get valid packaging. not sure how probably 
> this will be
> 3. there's a number of seemingly superfluous settings that i don't believe 
> serve any purpose and should be removed. validate that that they can be 
> removed and if not, figure out what they are so the don't seem so superfluous 
> any more.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1449) Streamline gremlin-python build

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1449.
---
Resolution: Fixed

> Streamline gremlin-python build
> ---
>
> Key: TINKERPOP-1449
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1449
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release, python
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.3
>
>
> Seems like there is a bit of extra processing and stuff going on in the 
> gremlin-python build automation. Most notably:
> 1. there are two executions of jython when only one seems necessary
> 2. doing a -DskipTests skips more stuff than it probably should - would be 
> nice to skip testing and still get valid packaging. not sure how probably 
> this will be
> 3. there's a number of seemingly superfluous settings that i don't believe 
> serve any purpose and should be removed. validate that that they can be 
> removed and if not, figure out what they are so the don't seem so superfluous 
> any more.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1448) gremlin-python should be Python 2/3 compatible

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1448:
-

> gremlin-python should be Python 2/3 compatible
> --
>
> Key: TINKERPOP-1448
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1448
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.2.2
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.2.3
>
>
> As discussed here, it is simple to maintain Python 2/3 compatibility for 
> gremlin-python GLV: 
> https://lists.apache.org/thread.html/263739a38133be620dd32640fe997388e76b20379a3dae44b10d4442@%3Cdev.tinkerpop.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1444) Benchmark bytecode->Traversal creation and implement GremlinServer cache if necessary.

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1444.
---
Resolution: Fixed

> Benchmark bytecode->Traversal creation and implement GremlinServer cache if 
> necessary.
> --
>
> Key: TINKERPOP-1444
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1444
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: benchmark, process, server
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> Right now, when you send {{Bytecode}} to GremlinServer, it will convert the 
> bytecode to a traversal either via Java reflection (Gremlin-Java) or script 
> engine evaluation (e.g. Gremlin-Groovy, Gremlin-Python).
> We should see how fast the process is to go from Bytecode to Traversal and if 
> its "slow" we should create a {{Map}}-cache in 
> GremlinServer.
> The reasons it may be "slow" are:
> 1. {{JavaTranslator}} uses Java reflection to translate bytecode to traversal 
> and that code is a little "thick" and either should be optimized (if 
> possible) or, instead, bytecode/traversal translations should be cached.
> 2. {{Groovy/PythonTranslator}} uses string construction to generate a script 
> from the bytecode. While that script may be cached, it would be good if we 
> have a cache prior to that which simply just grabs the traversal from a 
> bytecode cache.
> I think that we will definitely want a cache as it should make things fast, 
> but it will be good to know how much faster prior to diving into such work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1444) Benchmark bytecode->Traversal creation and implement GremlinServer cache if necessary.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1444:

Component/s: (was: language-variant)

> Benchmark bytecode->Traversal creation and implement GremlinServer cache if 
> necessary.
> --
>
> Key: TINKERPOP-1444
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1444
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: benchmark, process, server
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> Right now, when you send {{Bytecode}} to GremlinServer, it will convert the 
> bytecode to a traversal either via Java reflection (Gremlin-Java) or script 
> engine evaluation (e.g. Gremlin-Groovy, Gremlin-Python).
> We should see how fast the process is to go from Bytecode to Traversal and if 
> its "slow" we should create a {{Map}}-cache in 
> GremlinServer.
> The reasons it may be "slow" are:
> 1. {{JavaTranslator}} uses Java reflection to translate bytecode to traversal 
> and that code is a little "thick" and either should be optimized (if 
> possible) or, instead, bytecode/traversal translations should be cached.
> 2. {{Groovy/PythonTranslator}} uses string construction to generate a script 
> from the bytecode. While that script may be cached, it would be good if we 
> have a cache prior to that which simply just grabs the traversal from a 
> bytecode cache.
> I think that we will definitely want a cache as it should make things fast, 
> but it will be good to know how much faster prior to diving into such work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1455) Provide String-based withStrategy()/withoutStrategy() for language variant usage

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1455.
---
Resolution: Fixed

> Provide String-based withStrategy()/withoutStrategy() for language variant 
> usage
> 
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why? 
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to 
> {{GraphTraversalSource}} by way of {{withXXX}}. For example: 
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a 
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective 
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1455) Provide String-based withStrategy()/withoutStrategy() for language variant usage

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1455:
-

> Provide String-based withStrategy()/withoutStrategy() for language variant 
> usage
> 
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why? 
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to 
> {{GraphTraversalSource}} by way of {{withXXX}}. For example: 
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a 
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective 
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1486) Improve API of RemoteConnection

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1486:

Component/s: (was: language-variant)

> Improve API of RemoteConnection
> ---
>
> Key: TINKERPOP-1486
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1486
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Kevin Gallardo
>Assignee: stephen mallette
> Fix For: 3.2.3
>
>
> Currently an implementor that wants to define a _RemoteConnection_ 
> implementation must return a _RemoteTraversal_ object from the 
> {{RemoteConnection#submit(Bytecode)}} method.
> Thus it needs to implement a specific _RemoteTraversal_ class. When 
> implementing a _RemoteTraversal_ we need to implement the methods {{next()}} 
> and {{hasNext()}}. However these methods never seem to get called. Moreover, 
> we need to implement the method {{nextTraverser()}} which is the one that is 
> actually going to get called, but the method is not abstract and it is not 
> natural to understand that this particular method needs to be implemented.
> It seems like all the other methods of _RemoteTraversal_ are never called as 
> well since it is only used in _RemoteStep_, which only calls 
> {{nextTraverser()}}. I wonder if we could stop using the _RemoteTraversal_ 
> and instead have the {{submit()}} method return a simple abstract class that 
> has:
> - abstract method {{nextTraverser()}} returns _Traverser_
> - abstract method {{getSideEffects()}} returns _SideEffects_
> - possibly extend it later with others



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1455) Provide String-based withStrategy()/withoutStrategy() for language variant usage

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1455:

Component/s: (was: language-variant)

> Provide String-based withStrategy()/withoutStrategy() for language variant 
> usage
> 
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why? 
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to 
> {{GraphTraversalSource}} by way of {{withXXX}}. For example: 
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a 
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective 
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1507.
---
Resolution: Fixed

> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
> 
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, process, python
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.0, 3.2.3
>
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}}, 
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support 
> "default" and "all"-type semantics in switch behavior. We need to add it to 
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single 
> Java file.
> {code}
> public class Tokens {
>   public enum T { .. }
>   public enum Order { .. }
>   public enum VertexCardinality { ..}
>   public enum Compare { .. }
>   public enum Pick { .. } 
>   ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and 
> will be better able to use reflection in language variant generators.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1486) Improve API of RemoteConnection

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1486.
---
Resolution: Fixed

> Improve API of RemoteConnection
> ---
>
> Key: TINKERPOP-1486
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1486
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Kevin Gallardo
>Assignee: stephen mallette
> Fix For: 3.2.3
>
>
> Currently an implementor that wants to define a _RemoteConnection_ 
> implementation must return a _RemoteTraversal_ object from the 
> {{RemoteConnection#submit(Bytecode)}} method.
> Thus it needs to implement a specific _RemoteTraversal_ class. When 
> implementing a _RemoteTraversal_ we need to implement the methods {{next()}} 
> and {{hasNext()}}. However these methods never seem to get called. Moreover, 
> we need to implement the method {{nextTraverser()}} which is the one that is 
> actually going to get called, but the method is not abstract and it is not 
> natural to understand that this particular method needs to be implemented.
> It seems like all the other methods of _RemoteTraversal_ are never called as 
> well since it is only used in _RemoteStep_, which only calls 
> {{nextTraverser()}}. I wonder if we could stop using the _RemoteTraversal_ 
> and instead have the {{submit()}} method return a simple abstract class that 
> has:
> - abstract method {{nextTraverser()}} returns _Traverser_
> - abstract method {{getSideEffects()}} returns _SideEffects_
> - possibly extend it later with others



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1444) Benchmark bytecode->Traversal creation and implement GremlinServer cache if necessary.

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1444:
-

> Benchmark bytecode->Traversal creation and implement GremlinServer cache if 
> necessary.
> --
>
> Key: TINKERPOP-1444
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1444
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: benchmark, language-variant, process, server
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> Right now, when you send {{Bytecode}} to GremlinServer, it will convert the 
> bytecode to a traversal either via Java reflection (Gremlin-Java) or script 
> engine evaluation (e.g. Gremlin-Groovy, Gremlin-Python).
> We should see how fast the process is to go from Bytecode to Traversal and if 
> its "slow" we should create a {{Map}}-cache in 
> GremlinServer.
> The reasons it may be "slow" are:
> 1. {{JavaTranslator}} uses Java reflection to translate bytecode to traversal 
> and that code is a little "thick" and either should be optimized (if 
> possible) or, instead, bytecode/traversal translations should be cached.
> 2. {{Groovy/PythonTranslator}} uses string construction to generate a script 
> from the bytecode. While that script may be cached, it would be good if we 
> have a cache prior to that which simply just grabs the traversal from a 
> bytecode cache.
> I think that we will definitely want a cache as it should make things fast, 
> but it will be good to know how much faster prior to diving into such work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1440) g:Path needs a GraphSON deserializer in Gremlin-Python

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1440:
-

> g:Path needs a GraphSON deserializer in Gremlin-Python
> --
>
> Key: TINKERPOP-1440
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1440
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1440) g:Path needs a GraphSON deserializer in Gremlin-Python

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1440.
---
Resolution: Fixed

> g:Path needs a GraphSON deserializer in Gremlin-Python
> --
>
> Key: TINKERPOP-1440
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1440
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1507:

Component/s: (was: language-variant)
 python

> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
> 
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, process, python
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3, 3.3.0
>
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}}, 
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support 
> "default" and "all"-type semantics in switch behavior. We need to add it to 
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single 
> Java file.
> {code}
> public class Tokens {
>   public enum T { .. }
>   public enum Order { .. }
>   public enum VertexCardinality { ..}
>   public enum Compare { .. }
>   public enum Pick { .. } 
>   ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and 
> will be better able to use reflection in language variant generators.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)