[GitHub] tinkerpop issue #780: improve performace by not handling excepptions

[artem-aliev]

Github user artem-aliev commented on the issue:

https://github.com/apache/tinkerpop/pull/780
  
retargeted/rebase to latest tp32


---

[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

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

Github user jbmusso commented on the issue:

https://github.com/apache/tinkerpop/pull/695
  
According to https://github.com/petkaantonov/bluebird/issues/1026, users 
should be able to just patch the global `Promise` object in their application 
with:
```javascript
global.Promise = require("bluebird");
```
I am unsure about other Promise libraries but I believe this approach 
should work as long as they're Promise/A+ standard compliant. Maybe we could 
also give it more thoughts and see for other ways to handle this in a future 
release, but I think it's worth making the code simpler at this point. I also 
feel it can/should be done at the application level.


For Traversal methods, I didn't think about IDEs and you're absolutely 
right about code completion. I think your proposed approach with 
`callOnEmptyTraversal` works best. This makes me think that I'm pretty sure 
people will want typed traversals with TypeScript or FlowType soon (thinking 
about https://github.com/DefinitelyTyped/DefinitelyTyped here for example).




> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: javascript
>Affects Versions: 3.2.5
>Reporter: Jorge Bay
>Priority: Major
>
> It would be nice to have a Javascript Gremlin Language Variant that could 
> work with any ES5 runtime, specially the ones that support 
> [CommonJs|http://requirejs.org/docs/commonjs.html], like Node.js.
> Nashorn, the engine shipped with JDK 8+, does not implement CommonJs but 
> provides [additional 
> extensions|https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions] 
> making modular JavaScript possible. Nashorn should be supported in order to 
> run glv tests under the same infrastructure (JDK8).



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

[GitHub] tinkerpop issue #695: TINKERPOP-1489 JavaScript GLV

[jbmusso]

Github user jbmusso commented on the issue:

https://github.com/apache/tinkerpop/pull/695
  
According to https://github.com/petkaantonov/bluebird/issues/1026, users 
should be able to just patch the global `Promise` object in their application 
with:
```javascript
global.Promise = require("bluebird");
```
I am unsure about other Promise libraries but I believe this approach 
should work as long as they're Promise/A+ standard compliant. Maybe we could 
also give it more thoughts and see for other ways to handle this in a future 
release, but I think it's worth making the code simpler at this point. I also 
feel it can/should be done at the application level.


For Traversal methods, I didn't think about IDEs and you're absolutely 
right about code completion. I think your proposed approach with 
`callOnEmptyTraversal` works best. This makes me think that I'm pretty sure 
people will want typed traversals with TypeScript or FlowType soon (thinking 
about https://github.com/DefinitelyTyped/DefinitelyTyped here for example).




---

[GitHub] tinkerpop issue #778: TINKERPOP-1870: Extends TraverserSet to have Vertex in...

[artem-aliev]

Github user artem-aliev commented on the issue:

https://github.com/apache/tinkerpop/pull/778
  
rebased


---

[jira] [Commented] (TINKERPOP-1870) n^2 synchronious operation in OLAP WorkerExecutor.execute() method

[ASF GitHub Bot (JIRA)]

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

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

Github user artem-aliev commented on the issue:

https://github.com/apache/tinkerpop/pull/778
  
rebased


> n^2 synchronious operation in OLAP WorkerExecutor.execute() method
> --
>
> Key: TINKERPOP-1870
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1870
> Project: TinkerPop
>  Issue Type: Improvement
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Artem Aliev
>Priority: Major
> Attachments: findTraverser1.png, findTraverser2.png, 
> findTraverserFixed.png
>
>
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/traversal/WorkerExecutor.java#L80-L93]
> This block of code iterates over all remote traverses to select one related 
> to the current vertex and remove it. This operation is repeated for the next 
> vertex and so one. For following example query it means n^2 operations (n is 
> number of vertices). All of them in sync block. multi core spark executor 
> will do this operations serial. 
> {code}
> g.V().emit().repeat(both().dedup()).count().next()
> {code}
> See jvisualvm screenshot. 



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

[GitHub] tinkerpop issue #781: Tinkerpop 1870 master

[artem-aliev]

Github user artem-aliev commented on the issue:

https://github.com/apache/tinkerpop/pull/781
  
rebased 


---

[GitHub] tinkerpop issue #778: TINKERPOP-1870: Extends TraverserSet to have Vertex in...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/778
  
All tests pass with `docker/build.sh -t -i`

VOTE +1


---

[GitHub] tinkerpop pull request #784: TINKERPOP-1874 P does not appear to be serializ...

[spmallette]

GitHub user spmallette opened a pull request:

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

TINKERPOP-1874 P does not appear to be serialized consistently in GraphSON

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

Added  bunch of tests for this and found that .NET was still working, but 
that was just because of how the gherkin processor was generating the 
traversals (it was always converting `P` args to lists basically). I modified 
the `P` template for .NET and made it so that `within` and `without` are 
handled differently from the other enums - `within` and `without` will always 
pass a collection rather than an individual object if there is only one item 
present in the arg array.

I also updated the IO docs to include `within` and `without` so that it was 
clear to implementers what was expected for them. I may have to come back and 
do some cleanup here, but I already went deep on my PR to master for this so 
I'd rather just CTR in the doc fixes later.

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

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

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

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


commit 261b93b646c503068328d291224b430e4618410b
Author: Stephen Mallette 
Date:   2018-01-18T22:07:21Z

TINKERPOP-1874 Added tests around P

Validates various forms of serialization with focus on GraphSON and GLVs 
(where there were problems).

commit 822b33174c87a2a918b3fc9df421585a57ef3345
Author: Stephen Mallette 
Date:   2018-01-19T13:18:25Z

TINKERPOP-1874 keep P.within and P.without using collection

GraphSON deserialization of P.within and P.without expects a single 
collection regardless of the number of values, so even a single argument should 
serialize to a list.

commit 1c33340277612ba81ee751d8f91297621d9476de
Author: Stephen Mallette 
Date:   2018-01-19T13:37:29Z

TINKERPOP-1874 Added P.within/out graphson examples for io docs




---

[jira] [Commented] (TINKERPOP-1873) min() and max() work only in the range of Integer values

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1873:
---

For the protocol: not an issue in {{tp32/}}.

> min() and max() work only in the range of Integer values
> 
>
> Key: TINKERPOP-1873
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1873
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.3.1
>Reporter: Rado Kozmer
>Assignee: Daniel Kuppitz
>Priority: Major
>
> Following examples show the problem. The Min and Max steps are seeded with 
> Integer.MIN_VALUE and Integer.MAX_VALUE. This is not high/low enough for long 
> and double values.
> {{g.V(0).values().inject(99).min()}}
> returns 2147483647 instead of 99.
> {{g.V(0).values().inject(-99).max()}}
> returns -2147483648 instead of -99.
> Extremes like -Double.MAX_VALUE and Double.MAX_VALUE should solve the 
> problem, but I see some casting issues in the MinGlobalStep, MaxGlobalStep, 
> MinLocalStep, MaxLocalStep.
> Can anybody help with this?



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

[jira] [Commented] (TINKERPOP-1870) n^2 synchronious operation in OLAP WorkerExecutor.execute() method

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/778
  
All tests pass with `docker/build.sh -t -i`

VOTE +1


> n^2 synchronious operation in OLAP WorkerExecutor.execute() method
> --
>
> Key: TINKERPOP-1870
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1870
> Project: TinkerPop
>  Issue Type: Improvement
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Artem Aliev
>Priority: Major
> Attachments: findTraverser1.png, findTraverser2.png, 
> findTraverserFixed.png
>
>
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/traversal/WorkerExecutor.java#L80-L93]
> This block of code iterates over all remote traverses to select one related 
> to the current vertex and remove it. This operation is repeated for the next 
> vertex and so one. For following example query it means n^2 operations (n is 
> number of vertices). All of them in sync block. multi core spark executor 
> will do this operations serial. 
> {code}
> g.V().emit().repeat(both().dedup()).count().next()
> {code}
> See jvisualvm screenshot. 



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

[jira] [Commented] (TINKERPOP-1874) P does not appear to be serialized consistently in GraphSON

[ASF GitHub Bot (JIRA)]

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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1874 P does not appear to be serialized consistently in GraphSON

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

Added  bunch of tests for this and found that .NET was still working, but 
that was just because of how the gherkin processor was generating the 
traversals (it was always converting `P` args to lists basically). I modified 
the `P` template for .NET and made it so that `within` and `without` are 
handled differently from the other enums - `within` and `without` will always 
pass a collection rather than an individual object if there is only one item 
present in the arg array.

I also updated the IO docs to include `within` and `without` so that it was 
clear to implementers what was expected for them. I may have to come back and 
do some cleanup here, but I already went deep on my PR to master for this so 
I'd rather just CTR in the doc fixes later.

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

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

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

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


commit 261b93b646c503068328d291224b430e4618410b
Author: Stephen Mallette 
Date:   2018-01-18T22:07:21Z

TINKERPOP-1874 Added tests around P

Validates various forms of serialization with focus on GraphSON and GLVs 
(where there were problems).

commit 822b33174c87a2a918b3fc9df421585a57ef3345
Author: Stephen Mallette 
Date:   2018-01-19T13:18:25Z

TINKERPOP-1874 keep P.within and P.without using collection

GraphSON deserialization of P.within and P.without expects a single 
collection regardless of the number of values, so even a single argument should 
serialize to a list.

commit 1c33340277612ba81ee751d8f91297621d9476de
Author: Stephen Mallette 
Date:   2018-01-19T13:37:29Z

TINKERPOP-1874 Added P.within/out graphson examples for io docs




> P does not appear to be serialized consistently in GraphSON
> ---
>
> Key: TINKERPOP-1874
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1874
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> {{P}} deserialization seems to expect {{List}} arguments for collection 
> oriented operators like {{within}} and {{outside}} so {{P.without("x")}} 
> should wrap "x" in a {{List}} for serialization purposes. This causes 
> weirdness in some GLVs. For example in .NET we see that the use of 
> {{P.without("x")}} fails to deserialize the bytecode, but {{P.Without(new 
> List{"x"})}} will work fine. Just need to get this all straight and 
> consistent.



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

[jira] [Assigned] (TINKERPOP-1873) min() and max() work only in the range of Integer values

[stephen mallette (JIRA)]

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

stephen mallette reassigned TINKERPOP-1873:
---

Assignee: Daniel Kuppitz

> min() and max() work only in the range of Integer values
> 
>
> Key: TINKERPOP-1873
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1873
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.3.1
>Reporter: Rado Kozmer
>Assignee: Daniel Kuppitz
>Priority: Major
>
> Following examples show the problem. The Min and Max steps are seeded with 
> Integer.MIN_VALUE and Integer.MAX_VALUE. This is not high/low enough for long 
> and double values.
> {{g.V(0).values().inject(99).min()}}
> returns 2147483647 instead of 99.
> {{g.V(0).values().inject(-99).max()}}
> returns -2147483648 instead of -99.
> Extremes like -Double.MAX_VALUE and Double.MAX_VALUE should solve the 
> problem, but I see some casting issues in the MinGlobalStep, MaxGlobalStep, 
> MinLocalStep, MaxLocalStep.
> Can anybody help with this?



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

[jira] [Commented] (TINKERPOP-1874) P does not appear to be serialized consistently in GraphSON

[ASF GitHub Bot (JIRA)]

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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1874 master 

See #784 on tp32 for specific details. This change has a lot of extra stuff 
because I included IO test resources for 3.3.2 to `gremlin-io-test` so that I 
could also include the new `P` objects in that part of the test suite. 
Unfortunately, that made this PR look more complex than it is. There's really 
no additional changes of substance for solving the actual problem beyond what 
was in #784

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

VOTE +1

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

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

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

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


commit 261b93b646c503068328d291224b430e4618410b
Author: Stephen Mallette 
Date:   2018-01-18T22:07:21Z

TINKERPOP-1874 Added tests around P

Validates various forms of serialization with focus on GraphSON and GLVs 
(where there were problems).

commit 822b33174c87a2a918b3fc9df421585a57ef3345
Author: Stephen Mallette 
Date:   2018-01-19T13:18:25Z

TINKERPOP-1874 keep P.within and P.without using collection

GraphSON deserialization of P.within and P.without expects a single 
collection regardless of the number of values, so even a single argument should 
serialize to a list.

commit 1c33340277612ba81ee751d8f91297621d9476de
Author: Stephen Mallette 
Date:   2018-01-19T13:37:29Z

TINKERPOP-1874 Added P.within/out graphson examples for io docs

commit 7eaaa25d28955695a71d48814f818649927c0264
Author: Stephen Mallette 
Date:   2018-01-19T14:18:16Z

Merge branch 'TINKERPOP-1874' into TINKERPOP-1874-master

Conflicts:
docs/src/dev/io/graphson.asciidoc

gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/filter/GroovyHasTest.groovy

commit 334314fb580a3ddb3603c44431aaf060f85bc729
Author: Stephen Mallette 
Date:   2018-01-19T14:53:47Z

TINKERPOP-1874 Added IO compatibility tests on P.within/out

Also added data for all the IO Tests for 3.3.2

commit e8cb62820bb7b1ed6dfc1473ee7c99c2febf0552
Author: Stephen Mallette 
Date:   2018-01-19T15:38:11Z

TINKERPOP-1874 Added some dev docs on IO testing/docs




> P does not appear to be serialized consistently in GraphSON
> ---
>
> Key: TINKERPOP-1874
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1874
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> {{P}} deserialization seems to expect {{List}} arguments for collection 
> oriented operators like {{within}} and {{outside}} so {{P.without("x")}} 
> should wrap "x" in a {{List}} for serialization purposes. This causes 
> weirdness in some GLVs. For example in .NET we see that the use of 
> {{P.without("x")}} fails to deserialize the bytecode, but {{P.Without(new 
> List{"x"})}} will work fine. Just need to get this all straight and 
> consistent.



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

[GitHub] tinkerpop pull request #782: Initial commit for sparql-gremlin changes

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] tinkerpop pull request #785: TINKERPOP-1874 master

[spmallette]

GitHub user spmallette opened a pull request:

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

TINKERPOP-1874 master 

See #784 on tp32 for specific details. This change has a lot of extra stuff 
because I included IO test resources for 3.3.2 to `gremlin-io-test` so that I 
could also include the new `P` objects in that part of the test suite. 
Unfortunately, that made this PR look more complex than it is. There's really 
no additional changes of substance for solving the actual problem beyond what 
was in #784

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

VOTE +1

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

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

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

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


commit 261b93b646c503068328d291224b430e4618410b
Author: Stephen Mallette 
Date:   2018-01-18T22:07:21Z

TINKERPOP-1874 Added tests around P

Validates various forms of serialization with focus on GraphSON and GLVs 
(where there were problems).

commit 822b33174c87a2a918b3fc9df421585a57ef3345
Author: Stephen Mallette 
Date:   2018-01-19T13:18:25Z

TINKERPOP-1874 keep P.within and P.without using collection

GraphSON deserialization of P.within and P.without expects a single 
collection regardless of the number of values, so even a single argument should 
serialize to a list.

commit 1c33340277612ba81ee751d8f91297621d9476de
Author: Stephen Mallette 
Date:   2018-01-19T13:37:29Z

TINKERPOP-1874 Added P.within/out graphson examples for io docs

commit 7eaaa25d28955695a71d48814f818649927c0264
Author: Stephen Mallette 
Date:   2018-01-19T14:18:16Z

Merge branch 'TINKERPOP-1874' into TINKERPOP-1874-master

Conflicts:
docs/src/dev/io/graphson.asciidoc

gremlin-groovy-test/src/main/groovy/org/apache/tinkerpop/gremlin/process/traversal/step/filter/GroovyHasTest.groovy

commit 334314fb580a3ddb3603c44431aaf060f85bc729
Author: Stephen Mallette 
Date:   2018-01-19T14:53:47Z

TINKERPOP-1874 Added IO compatibility tests on P.within/out

Also added data for all the IO Tests for 3.3.2

commit e8cb62820bb7b1ed6dfc1473ee7c99c2febf0552
Author: Stephen Mallette 
Date:   2018-01-19T15:38:11Z

TINKERPOP-1874 Added some dev docs on IO testing/docs




---

[jira] [Commented] (TINKERPOP-1875) Gremlin-Python only aggregates to list when using GraphSON3

[David M. Brown (JIRA)]

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

David M. Brown commented on TINKERPOP-1875:
---

Now that I look a bit more closely at the message format, I see what is going 
on.In v2 meta, etc. were all pretty much top level keys in the JSON response 
from the server. Now that meta and status have type info they need to be 
deserialized more carefully. I'll fix this up.

> Gremlin-Python only aggregates to list when using GraphSON3
> ---
>
> Key: TINKERPOP-1875
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1875
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.1
>Reporter: David M. Brown
>Assignee: David M. Brown
>Priority: Major
> Fix For: 3.3.2
>
>
> Gremlin-Python fails to correctly extract the aggregate_to value from the 
> Gremlin Server response when using GraphSON3. I believe this is the source of 
> the test failures that were temporarily fixed by using the v2.0 message 
> serializer in [this 
> commit|https://github.com/apache/tinkerpop/commit/8c299879e65748c2c2b03a58b6d0c5c401de].
>  
> In general, it seems this value is a bit buried in the new response message 
> format:
> {code:json}
> {'requestId': 'b2a51ad2-bca6-4493-9115-a57a92e477c7',
>  'result': {'data': {'@type': 'g:List',
>'@value': [{'@type': 'g:Map',
>  '@value': ['ripple', {'@type': 'g:Int64', '@value': 1}]},
> {'@type': 'g:Map', '@value': ['lop', {'@type': 'g:Int64', '@value': 
> 3}]}]},
>   'meta': {'@type': 'g:Map',
>'@value': ['aggregateTo', 'map', 'sideEffectKey', 'm']}},
>  'status': {'attributes': {'@type': 'g:Map', '@value': []},
>   'code': 200,
>   'message': ''}}
> {code}
> To access it, you have to do something like:
> {code:python}
> message['result']['meta']['@value'][1]
> {code}
> Which throws an error when no metadata is present. This seems a bit clumsy. I 
> haven't looked at how the Java driver deals with it, maybe there is a better 
> way to parse this.



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

[jira] [Commented] (TINKERPOP-1875) Gremlin-Python only aggregates to list when using GraphSON3

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1875:
-

The driver handles it with a default to "none" if data in "meta" is not present:

https://github.com/apache/tinkerpop/blob/cb8109479a744fa7c149bd380ac560561c3d141a/gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/Handler.java#L227

> Gremlin-Python only aggregates to list when using GraphSON3
> ---
>
> Key: TINKERPOP-1875
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1875
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.1
>Reporter: David M. Brown
>Assignee: David M. Brown
>Priority: Major
> Fix For: 3.3.2
>
>
> Gremlin-Python fails to correctly extract the aggregate_to value from the 
> Gremlin Server response when using GraphSON3. I believe this is the source of 
> the test failures that were temporarily fixed by using the v2.0 message 
> serializer in [this 
> commit|https://github.com/apache/tinkerpop/commit/8c299879e65748c2c2b03a58b6d0c5c401de].
>  
> In general, it seems this value is a bit buried in the new response message 
> format:
> {code:json}
> {'requestId': 'b2a51ad2-bca6-4493-9115-a57a92e477c7',
>  'result': {'data': {'@type': 'g:List',
>'@value': [{'@type': 'g:Map',
>  '@value': ['ripple', {'@type': 'g:Int64', '@value': 1}]},
> {'@type': 'g:Map', '@value': ['lop', {'@type': 'g:Int64', '@value': 
> 3}]}]},
>   'meta': {'@type': 'g:Map',
>'@value': ['aggregateTo', 'map', 'sideEffectKey', 'm']}},
>  'status': {'attributes': {'@type': 'g:Map', '@value': []},
>   'code': 200,
>   'message': ''}}
> {code}
> To access it, you have to do something like:
> {code:python}
> message['result']['meta']['@value'][1]
> {code}
> Which throws an error when no metadata is present. This seems a bit clumsy. I 
> haven't looked at how the Java driver deals with it, maybe there is a better 
> way to parse this.



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

[GitHub] tinkerpop issue #695: TINKERPOP-1489 JavaScript GLV

[jorgebay]

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/695
  
Rebased.


---

[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

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

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/695
  
Rebased.


> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: javascript
>Affects Versions: 3.2.5
>Reporter: Jorge Bay
>Priority: Major
>
> It would be nice to have a Javascript Gremlin Language Variant that could 
> work with any ES5 runtime, specially the ones that support 
> [CommonJs|http://requirejs.org/docs/commonjs.html], like Node.js.
> Nashorn, the engine shipped with JDK 8+, does not implement CommonJs but 
> provides [additional 
> extensions|https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions] 
> making modular JavaScript possible. Nashorn should be supported in order to 
> run glv tests under the same infrastructure (JDK8).



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