[jira] [Commented] (TINKERPOP-1582) TraversalOpProcessor does not support custom serializers

[ASF GitHub Bot (JIRA)]

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

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

GitHub user bjmoor opened a pull request:

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

TINKERPOP-1582 - Encode Bytecode as a dict, not a string

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

Remote connection driver was encoding the Gremlin Bytecode as a json 
string, rather than as a dict.  This caused the TraversalOpProcessor to not use 
the gremlin-server configured deserializers, but rather a non-configurable 
statically declared serializer to decode the Bytecode string.

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

$ git pull https://github.com/bjmoor/tinkerpop TINKERPOP-1582

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

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


commit 0b74ea40aacaab519357626fa4c2c580ffe6b148
Author: Branden Moore 
Date:   2016-12-07T19:53:38Z

[driver_remote] Encode Bytecode as a dict, not a string




> TraversalOpProcessor does not support custom serializers
> 
>
> Key: TINKERPOP-1582
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1582
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.3
>Reporter: Branden Moore
>
> The TraversalOpProcessor has its own ObjectMapper static instance, which 
> cannot be configured via the gremlin-server's YAML file.  Within the YAML 
> file, a user can configure serializers with custom IORegistries, to support 
> serialization of custom types.   However, the TraversalOpProcessor creates 
> its own ObjectMapper, for bytecode deserialization, which does not read 
> configuration information from from the YAML file.
> This prevents deserialization of custom bytecode, such as references to a 
> custom Predicate class.



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

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1583:
---

Thanks for reporting this [~gereedy].  I'll take a look.

> PathRetractionStrategy retracts keys that are actually needed
> -
>
> Key: TINKERPOP-1583
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1583
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Geoff Reedy
>
> We've seen this specifically for labels used in the until modulator of repeat 
> but I suspect it happens for other modulators as well. Here's a test case:
> {code}
> graph = TinkerGraph.open()
> g = graph.traversal()
> g.addV().as("first").repeat(addE("next").to(addV()).inV()).times(5).addE("next").to(select("first")).iterate()
> g.V().limit(1).as('z').out().repeat(store('seen').out().where(without('seen'))).until(where(eq('z')))
> {code}
> complains there is no z-key
> I tired to fix it myself and submit a pull request but I found the 
> implementation of PathRetractionStrategy confusing.
> One thing I noticed is that it seems the set of labels a step needs present 
> in order to work properly is determined external to the steps and that code 
> includes a lot of type-tests. If that logic were pushed down into the step 
> implementations I think fixing the repeat case would be easier and it would 
> be possible for extension steps to work properly with this strategy 
> (currently it seems they can't because of the closed-world assumption 
> inherent in the type-casing).



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

[jira] [Assigned] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[Ted Wilmes (JIRA)]

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

Ted Wilmes reassigned TINKERPOP-1583:
-

Assignee: Ted Wilmes

> PathRetractionStrategy retracts keys that are actually needed
> -
>
> Key: TINKERPOP-1583
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1583
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Geoff Reedy
>Assignee: Ted Wilmes
>
> We've seen this specifically for labels used in the until modulator of repeat 
> but I suspect it happens for other modulators as well. Here's a test case:
> {code}
> graph = TinkerGraph.open()
> g = graph.traversal()
> g.addV().as("first").repeat(addE("next").to(addV()).inV()).times(5).addE("next").to(select("first")).iterate()
> g.V().limit(1).as('z').out().repeat(store('seen').out().where(without('seen'))).until(where(eq('z')))
> {code}
> complains there is no z-key
> I tired to fix it myself and submit a pull request but I found the 
> implementation of PathRetractionStrategy confusing.
> One thing I noticed is that it seems the set of labels a step needs present 
> in order to work properly is determined external to the steps and that code 
> includes a lot of type-tests. If that logic were pushed down into the step 
> implementations I think fixing the repeat case would be easier and it would 
> be possible for extension steps to work properly with this strategy 
> (currently it seems they can't because of the closed-world assumption 
> inherent in the type-casing).



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

Re: Distributed OLTP and Dynamic Query Routing with Akka

[Marko Rodriguez]

Hello,

So Distributed OLTP is done. I was able to get barriers, side-effects, 
auto-halting, stalling traversers for bulking, etc. implemented since this 
morning and well, tada.

There are more classes now, so here is a link to the package root. Again, this 
is just a test/ package in TinkerGraph for now to make it easy for me to play.


https://github.com/apache/tinkerpop/tree/TINKERPOP-1564/tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/process/akka
 


In TinkerActorSystem, you will see 3 traversals that executed in the public 
static main(). Here is the output.

EXECUTING: [[withStrategies(VertexProgramStrategy)], [V(), match([[], [as(a), 
out(created), as(b)]], [[], [as(b), in(created), as(c)]], [[], [as(b), 
has(name, eq(lop))]]), where(a, neq(c)), select(a, b, c), by(name)]]
master[created]: akka://traversal-1552478766/user/master
worker[created]: akka://traversal-1552478766/user/master/worker-765740875
worker[created]: akka://traversal-1552478766/user/master/worker-458575643
worker[created]: akka://traversal-1552478766/user/master/worker-2134136508
master[result]: {a=peter, b=lop, c=josh}
master[result]: {a=marko, b=lop, c=peter}
master[result]: {a=josh, b=lop, c=marko}
master[result]: {a=josh, b=lop, c=peter}
master[result]: {a=peter, b=lop, c=marko}
master[result]: {a=marko, b=lop, c=josh}
//

EXECUTING: [[withStrategies(VertexProgramStrategy)], [V(), repeat([[], 
[both()]]), times(2), groupCount(a), by(name), cap(a), select(keys), unfold(), 
limit(3)]]
master[created]: akka://traversal--116529363/user/master
worker[created]: akka://traversal--116529363/user/master/worker-97122649
worker[created]: akka://traversal--116529363/user/master/worker-32927032
worker[created]: akka://traversal--116529363/user/master/worker-1156903778
master[result]: ripple
master[result]: peter
master[result]: vadas
//

EXECUTING: [[withStrategies(VertexProgramStrategy)], [V(), repeat([[], 
[both()]]), times(2), hasLabel(person), group(), by(name), by([[], 
[out(created), values(name), dedup(), fold()]])]]
master[created]: akka://traversal--558368687/user/master
worker[created]: akka://traversal--558368687/user/master/worker-704359101
worker[created]: akka://traversal--558368687/user/master/worker-767830874
worker[created]: akka://traversal--558368687/user/master/worker-1757847686
master[result]: {peter=[lop], vadas=[], josh=[ripple, lop], marko=[lop]}
//

Why are these traversals cool?

1. match() works.
2. side-effects work.
3. reducing barriers work and check it, you can traverser beyond the 
local star graph!

What really opened everything up was realizing I could implement my own Mailbox.


https://github.com/apache/tinkerpop/blob/TINKERPOP-1564/tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/process/akka/TraverserMailbox.java
 


This allows me to order how certain types of messages are read by the actors 
and most importantly, allows me to back Traverser messages by a TraverserSet 
and thus, we now have the bulking optimization.

So freakin’ cool.

Enjoy!,
Marko.

http://markorodriguez.com



> On Dec 7, 2016, at 5:13 AM, Marko Rodriguez  wrote:
> 
> Hello,
> 
> I have been studying Akka lately as a way to implement distributed 
> OLTP/dynamic query routing. I have a working implementation.
> 
> This is a “toy implementation” currently in the TINKERPOP-1564 test/ of 
> tinkergraph-gremlin.
> 
> There are 3 classes: 
> 
> TinkerActorSystem
>   
> https://github.com/apache/tinkerpop/blob/0462411f1d1ad6fab9d3e6e58e5e158c9bb3f207/tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/process/akka/TinkerActorSystem.java
>  
> 
> This class creates an Akka ActorSystem for a submitted traversal. It then 
> spawns a MasterTraversalActor given the traversal and a partitioner. The 
> partitioner is currently hardcoded.
> 
> MasterTraversalActor
>   
> https://github.com/apache/tinkerpop/blob/0462411f1d1ad6fab9d3e6e58e5e158c9bb3f207/tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/process/akka/MasterTraversalActor.java
>  
> 
> This class spawns a WorkerTraversalActor 

[jira] [Created] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[Geoff Reedy (JIRA)]

Geoff Reedy created TINKERPOP-1583:
--

 Summary: PathRetractionStrategy retracts keys that are actually 
needed
 Key: TINKERPOP-1583
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1583
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.3
Reporter: Geoff Reedy


We've seen this specifically for labels used in the until modulator of repeat 
but I suspect it happens for other modulators as well. Here's a test case:

{code}
graph = TinkerGraph.open()
g = graph.traversal()
g.addV().as("first").repeat(addE("next").to(addV()).inV()).times(5).addE("next").to(select("first")).iterate()
g.V().limit(1).as('z').out().repeat(store('seen').out().where(without('seen'))).until(where(eq('z')))
{code}

complains there is no z-key

I tired to fix it myself and submit a pull request but I found the 
implementation of PathRetractionStrategy confusing.

One thing I noticed is that it seems the set of labels a step needs present in 
order to work properly is determined external to the steps and that code 
includes a lot of type-tests. If that logic were pushed down into the step 
implementations I think fixing the repeat case would be easier and it would be 
possible for extension steps to work properly with this strategy (currently it 
seems they can't because of the closed-world assumption inherent in the 
type-casing).



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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user robertdale commented on the issue:

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


> Bump to Netty 4.0.42
> 
>
> Key: TINKERPOP-1570
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1570
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.4
>
>
> Mostly a bunch of bug fixes have come in the latest two versions of Netty - 
> not sure there is anything specific to TinkerPop that is currently known as a 
> problem, but it's probably good to keep up with these patch releases:
> http://netty.io/news/2016/08/29/4-0-41-Final-4-1-5-Final.html
> http://netty.io/news/2016/10/14/4-0-42-Final-4-1-6-Final.html



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

[GitHub] tinkerpop issue #512: TINKERPOP-1570 Bumped to Netty 4.0.42

[robertdale]

Github user robertdale commented on the issue:

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


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

[GitHub] tinkerpop issue #478: TINKERPOP-1490 Implemented promise API for Traversal

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
Rebase is complete now - tests are all good with:

```text
$ mvn clean install && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false -DincludeNeo4j
```


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

[jira] [Commented] (TINKERPOP-1490) Provider a Future based Traversal.async(Function<Traversal,V>) terminal step

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
Rebase is complete now - tests are all good with:

```text
$ mvn clean install && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false -DincludeNeo4j
```


> Provider a Future based Traversal.async(Function) terminal step
> 
>
> Key: TINKERPOP-1490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is 
> important for not only avoiding thread locking on a query in Gremlin, but 
> also, it will allow single threaded language variants like Gremlin-JavaScript 
> to use callbacks for processing query results.
> {code}
> Future result = 
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
>   // I don't know JavaScript, but ...
>   return list(names);
> }) 
> {code}
> ...



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

[GitHub] tinkerpop issue #478: TINKERPOP-1490 Implemented promise API for Traversal

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
I'm rebasing on `tp32` to clean up that conflict. this branch was pretty 
far behind.


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

[jira] [Commented] (TINKERPOP-1490) Provider a Future based Traversal.async(Function<Traversal,V>) terminal step

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
I'm rebasing on `tp32` to clean up that conflict. this branch was pretty 
far behind.


> Provider a Future based Traversal.async(Function) terminal step
> 
>
> Key: TINKERPOP-1490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is 
> important for not only avoiding thread locking on a query in Gremlin, but 
> also, it will allow single threaded language variants like Gremlin-JavaScript 
> to use callbacks for processing query results.
> {code}
> Future result = 
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
>   // I don't know JavaScript, but ...
>   return list(names);
> }) 
> {code}
> ...



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

[jira] [Commented] (TINKERPOP-1582) TraversalOpProcessor does not support custom serializers

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1582:
-

i think we should aim to do this at {{tp32}}. If you just change the client 
side in gremlin-python it should not represent a breaking change in any way.  I 
still can't think of any reason why it's passing that string or why the server 
needed to support both modes. Perhaps it is just a remnant of some original 
work and now it's just unnecessary. We can remove the server side support in 
3.3.0. 

As far as the {{writeObject()}} issue I think you should just leave it as 
returning a string since a change to the return type will break the interface. 
I think you can just call {{toDict()}} as the solution. 

There's a good body of tests to validate your changes that execute as part of 
the standard build of {{mvn clean install}} (assuming you have a ".glv" file in 
your gremlin-python directory. You can read more about that here:

http://tinkerpop.apache.org/docs/current/dev/developer/#python-environment

Hopefully that gets everything fixed up - thanks for doing this.

> TraversalOpProcessor does not support custom serializers
> 
>
> Key: TINKERPOP-1582
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1582
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.3
>Reporter: Branden Moore
>
> The TraversalOpProcessor has its own ObjectMapper static instance, which 
> cannot be configured via the gremlin-server's YAML file.  Within the YAML 
> file, a user can configure serializers with custom IORegistries, to support 
> serialization of custom types.   However, the TraversalOpProcessor creates 
> its own ObjectMapper, for bytecode deserialization, which does not read 
> configuration information from from the YAML file.
> This prevents deserialization of custom bytecode, such as references to a 
> custom Predicate class.



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

[GitHub] tinkerpop issue #478: TINKERPOP-1490 Implemented promise API for Traversal

[davebshow]

Github user davebshow commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
Well I implemented this API for gremlin-python. There is one major problem: 
side effects. Since the current side effect API is designed to be synchronous 
(calling `run_sync`), it cannot be used inside a coroutine, as  demonstrated by 
this 
[test](https://github.com/apache/tinkerpop/blob/54fac5146a5ac067e75f2fbfe135fae2da641c35/gremlin-python/src/main/jython/tests/driver/test_driver_remote_connection.py#L210).
 This is problematic for a Tornado or Asyncio based driver. I think in the 
future we should consider the possibility that the `promise()` method return a 
`AsyncSideEffect` object so the end user can leverage the async techniques with 
side effects.


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

[jira] [Commented] (TINKERPOP-1490) Provider a Future based Traversal.async(Function<Traversal,V>) terminal step

[ASF GitHub Bot (JIRA)]

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

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

Github user davebshow commented on the issue:

https://github.com/apache/tinkerpop/pull/478
  
Well I implemented this API for gremlin-python. There is one major problem: 
side effects. Since the current side effect API is designed to be synchronous 
(calling `run_sync`), it cannot be used inside a coroutine, as  demonstrated by 
this 
[test](https://github.com/apache/tinkerpop/blob/54fac5146a5ac067e75f2fbfe135fae2da641c35/gremlin-python/src/main/jython/tests/driver/test_driver_remote_connection.py#L210).
 This is problematic for a Tornado or Asyncio based driver. I think in the 
future we should consider the possibility that the `promise()` method return a 
`AsyncSideEffect` object so the end user can leverage the async techniques with 
side effects.


> Provider a Future based Traversal.async(Function) terminal step
> 
>
> Key: TINKERPOP-1490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant, process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is 
> important for not only avoiding thread locking on a query in Gremlin, but 
> also, it will allow single threaded language variants like Gremlin-JavaScript 
> to use callbacks for processing query results.
> {code}
> Future result = 
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
>   // I don't know JavaScript, but ...
>   return list(names);
> }) 
> {code}
> ...



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

[jira] [Commented] (TINKERPOP-1582) TraversalOpProcessor does not support custom serializers

[Branden Moore (JIRA)]

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

Branden Moore commented on TINKERPOP-1582:
--

I can submit one;  to which branch I should target?  Also, do you think 
{{GraphSONWriter.writeObject()}} should return the dict, or should we change to 
calling {{GraphSONWriter.toDict()}}?  Initially, either seems like it should 
work, but I'm less familiar with the design decisions around this.

> TraversalOpProcessor does not support custom serializers
> 
>
> Key: TINKERPOP-1582
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1582
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.3
>Reporter: Branden Moore
>
> The TraversalOpProcessor has its own ObjectMapper static instance, which 
> cannot be configured via the gremlin-server's YAML file.  Within the YAML 
> file, a user can configure serializers with custom IORegistries, to support 
> serialization of custom types.   However, the TraversalOpProcessor creates 
> its own ObjectMapper, for bytecode deserialization, which does not read 
> configuration information from from the YAML file.
> This prevents deserialization of custom bytecode, such as references to a 
> custom Predicate class.



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

[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
 Assignee: Marko A. Rodriguez
Fix Version/s: 3.2.4

> gremlin-python calls non-existent methods
> -
>
> Key: TINKERPOP-1576
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1576
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>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.3.4#6332)

[jira] [Commented] (TINKERPOP-1582) TraversalOpProcessor does not support custom serializers

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1582:
-

I guess that would do it. I think we should migrate away from the {{String}} 
approach (i'm not sure I remember why we allow it both ways). {{Bytecode}} 
should be processed as a bytecode "object" not an embedded string. Since you 
found the problem, do you want submit a pull request to fix that in 
gremlin-python (i.e. submit the bytecode dictionary and not the string)? if you 
don't have time, just let me know.

> TraversalOpProcessor does not support custom serializers
> 
>
> Key: TINKERPOP-1582
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1582
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.3
>Reporter: Branden Moore
>
> The TraversalOpProcessor has its own ObjectMapper static instance, which 
> cannot be configured via the gremlin-server's YAML file.  Within the YAML 
> file, a user can configure serializers with custom IORegistries, to support 
> serialization of custom types.   However, the TraversalOpProcessor creates 
> its own ObjectMapper, for bytecode deserialization, which does not read 
> configuration information from from the YAML file.
> This prevents deserialization of custom bytecode, such as references to a 
> custom Predicate class.



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

[jira] [Closed] (TINKERPOP-1536) Include GLVs in Docker build

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-1536.
-
Resolution: Fixed

Solved via https://github.com/apache/tinkerpop/pull/508

> Include GLVs in Docker build
> 
>
> Key: TINKERPOP-1536
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1536
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0
>
>
> This requires a change in the Docker container definitions, hence it should 
> only go into 3.3.0.



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

[jira] [Commented] (TINKERPOP-1582) TraversalOpProcessor does not support custom serializers

[Branden Moore (JIRA)]

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

Branden Moore commented on TINKERPOP-1582:
--

It appears that {{DriverRemoteConnection.submit_traversal_bytecode()}} assigns 
the {{"gremlin"}} arg's value as the result of the 
{{GraphSONWriter.writeObject()}}.  {{GraphSONWriter.writeObject()}} returns a 
json-formatted string, rather than a raw dictionary.   I believe this is the 
source of the problem.

> TraversalOpProcessor does not support custom serializers
> 
>
> Key: TINKERPOP-1582
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1582
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.3
>Reporter: Branden Moore
>
> The TraversalOpProcessor has its own ObjectMapper static instance, which 
> cannot be configured via the gremlin-server's YAML file.  Within the YAML 
> file, a user can configure serializers with custom IORegistries, to support 
> serialization of custom types.   However, the TraversalOpProcessor creates 
> its own ObjectMapper, for bytecode deserialization, which does not read 
> configuration information from from the YAML file.
> This prevents deserialization of custom bytecode, such as references to a 
> custom Predicate class.



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

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

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-1539.
-
   Resolution: Fixed
Fix Version/s: 3.2.4

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


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



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

[GitHub] tinkerpop pull request #511: TINKERPOP-1539 Create a ComplexTraversalTest wi...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[jira] [Commented] (TINKERPOP-1562) Migrate ScriptEngine-related code to gremlin-core

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/510#discussion_r91326812
  
--- Diff: 
hadoop-gremlin/src/main/java/org/apache/tinkerpop/gremlin/hadoop/jsr223/HadoopGremlinPlugin.java
 ---
@@ -0,0 +1,153 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.tinkerpop.gremlin.hadoop.jsr223;
+
+import org.apache.hadoop.conf.Configuration;
+import org.apache.hadoop.fs.FileSystem;
+import org.apache.hadoop.io.IOUtils;
+import org.apache.hadoop.io.compress.CodecPool;
+import org.apache.hadoop.mapreduce.lib.input.SequenceFileInputFormat;
+import org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat;
+import org.apache.hadoop.util.ToolRunner;
+import org.apache.tinkerpop.gremlin.hadoop.Constants;
+import 
org.apache.tinkerpop.gremlin.hadoop.process.computer.mapreduce.MapReduceGraphComputer;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopConfiguration;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopEdge;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopElement;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopGraph;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopProperty;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopVertex;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopVertexProperty;
+import org.apache.tinkerpop.gremlin.hadoop.structure.io.FileSystemStorage;
+import org.apache.tinkerpop.gremlin.hadoop.structure.io.VertexWritable;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.graphson.GraphSONInputFormat;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.graphson.GraphSONOutputFormat;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.graphson.GraphSONRecordReader;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.graphson.GraphSONRecordWriter;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoInputFormat;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoOutputFormat;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoRecordReader;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoRecordWriter;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.script.ScriptInputFormat;
+import org.apache.tinkerpop.gremlin.hadoop.structure.util.ConfUtil;
+import org.apache.tinkerpop.gremlin.jsr223.AbstractGremlinPlugin;
+import org.apache.tinkerpop.gremlin.jsr223.BindingsCustomizer;
+import org.apache.tinkerpop.gremlin.jsr223.Customizer;
+import org.apache.tinkerpop.gremlin.jsr223.DefaultImportCustomizer;
+import org.apache.tinkerpop.gremlin.jsr223.ImportCustomizer;
+import org.apache.tinkerpop.gremlin.jsr223.LazyBindingsCustomizer;
+import org.apache.tinkerpop.gremlin.jsr223.console.ConsoleCustomizer;
+import org.apache.tinkerpop.gremlin.jsr223.console.GremlinShellEnvironment;
+import org.apache.tinkerpop.gremlin.jsr223.console.RemoteAcceptor;
+
+import javax.script.Bindings;
+import javax.script.SimpleBindings;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Optional;
+import java.util.Set;
+
+/**
+ * @author Marko A. Rodriguez (http://markorodriguez.com)
+ */
+public final class HadoopGremlinPlugin extends AbstractGremlinPlugin {
+
+protected static String NAME = "tinkerpop.hadoop";
+
+private static final BindingsCustomizer bindings;
+
+private static final ImportCustomizer imports;
+
+private static final Set appliesTo = new 
HashSet<>(Collections.singletonList("gremlin-groovy"));
+
+static {
+try {
+// TODO: most of the imports here were 

[GitHub] tinkerpop pull request #510: TINKERPOP-1562 Migrate ScriptEngine-related cod...

[spmallette]

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

https://github.com/apache/tinkerpop/pull/510#discussion_r91326812
  
--- Diff: 
hadoop-gremlin/src/main/java/org/apache/tinkerpop/gremlin/hadoop/jsr223/HadoopGremlinPlugin.java
 ---
@@ -0,0 +1,153 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.tinkerpop.gremlin.hadoop.jsr223;
+
+import org.apache.hadoop.conf.Configuration;
+import org.apache.hadoop.fs.FileSystem;
+import org.apache.hadoop.io.IOUtils;
+import org.apache.hadoop.io.compress.CodecPool;
+import org.apache.hadoop.mapreduce.lib.input.SequenceFileInputFormat;
+import org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat;
+import org.apache.hadoop.util.ToolRunner;
+import org.apache.tinkerpop.gremlin.hadoop.Constants;
+import 
org.apache.tinkerpop.gremlin.hadoop.process.computer.mapreduce.MapReduceGraphComputer;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopConfiguration;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopEdge;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopElement;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopGraph;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopProperty;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopVertex;
+import org.apache.tinkerpop.gremlin.hadoop.structure.HadoopVertexProperty;
+import org.apache.tinkerpop.gremlin.hadoop.structure.io.FileSystemStorage;
+import org.apache.tinkerpop.gremlin.hadoop.structure.io.VertexWritable;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.graphson.GraphSONInputFormat;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.graphson.GraphSONOutputFormat;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.graphson.GraphSONRecordReader;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.graphson.GraphSONRecordWriter;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoInputFormat;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoOutputFormat;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoRecordReader;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoRecordWriter;
+import 
org.apache.tinkerpop.gremlin.hadoop.structure.io.script.ScriptInputFormat;
+import org.apache.tinkerpop.gremlin.hadoop.structure.util.ConfUtil;
+import org.apache.tinkerpop.gremlin.jsr223.AbstractGremlinPlugin;
+import org.apache.tinkerpop.gremlin.jsr223.BindingsCustomizer;
+import org.apache.tinkerpop.gremlin.jsr223.Customizer;
+import org.apache.tinkerpop.gremlin.jsr223.DefaultImportCustomizer;
+import org.apache.tinkerpop.gremlin.jsr223.ImportCustomizer;
+import org.apache.tinkerpop.gremlin.jsr223.LazyBindingsCustomizer;
+import org.apache.tinkerpop.gremlin.jsr223.console.ConsoleCustomizer;
+import org.apache.tinkerpop.gremlin.jsr223.console.GremlinShellEnvironment;
+import org.apache.tinkerpop.gremlin.jsr223.console.RemoteAcceptor;
+
+import javax.script.Bindings;
+import javax.script.SimpleBindings;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Optional;
+import java.util.Set;
+
+/**
+ * @author Marko A. Rodriguez (http://markorodriguez.com)
+ */
+public final class HadoopGremlinPlugin extends AbstractGremlinPlugin {
+
+protected static String NAME = "tinkerpop.hadoop";
+
+private static final BindingsCustomizer bindings;
+
+private static final ImportCustomizer imports;
+
+private static final Set appliesTo = new 
HashSet<>(Collections.singletonList("gremlin-groovy"));
+
+static {
+try {
+// TODO: most of the imports here were wildcarded, but we 
dont' allow that anymore - needs review
+imports = DefaultImportCustomizer.build()
+.addClassImports(
+Configuration.class,
+

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

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

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


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



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

Default to GraphSON 2.0

[Stephen Mallette]

I just pushed https://issues.apache.org/jira/browse/TINKERPOP-1414 onto
TINKERPOP-1565 branch as it was related. Note that this work is targeted
for 3.3.0.

Basically, this change means that Gremlin Server and TinkerGraph both
default to GraphSON 2.0 for 3.3.0. It's a breaking change only if you
happened to still use "application/json" as your serialization method. I
suspect that this break would affect REST API users the most, but it's
relatively simple to re-configure Gremlin Server to work the old way. It's
a one line change in gremlin-server.yaml which is written clearly in the
upgrade docs.

[jira] [Updated] (TINKERPOP-1414) Change default GraphSON version to 2.0

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1414:

Labels: breaking  (was: )

> Change default GraphSON version to 2.0
> --
>
> Key: TINKERPOP-1414
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1414
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.1
>Reporter: stephen mallette
>  Labels: breaking
> Fix For: 3.3.0
>
>
> At 3.3.0 we should probably make GraphSON 2.0 the default version.



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

[jira] [Commented] (TINKERPOP-1414) Change default GraphSON version to 2.0

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1414:
-

This will be implemented on the TINKERPOP-1565

> Change default GraphSON version to 2.0
> --
>
> Key: TINKERPOP-1414
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1414
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.1
>Reporter: stephen mallette
> Fix For: 3.3.0
>
>
> At 3.3.0 we should probably make GraphSON 2.0 the default version.



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

[jira] [Commented] (TINKERPOP-1582) TraversalOpProcessor does not support custom serializers

[Robert Dale (JIRA)]

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

Robert Dale commented on TINKERPOP-1582:


Not that this solves your problem, but 'g' is the gremlin namespace. Ideally, 
you would use your own namespace, e.g. 
{noformat}
snl:MyP
{noformat}

> TraversalOpProcessor does not support custom serializers
> 
>
> Key: TINKERPOP-1582
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1582
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.3
>Reporter: Branden Moore
>
> The TraversalOpProcessor has its own ObjectMapper static instance, which 
> cannot be configured via the gremlin-server's YAML file.  Within the YAML 
> file, a user can configure serializers with custom IORegistries, to support 
> serialization of custom types.   However, the TraversalOpProcessor creates 
> its own ObjectMapper, for bytecode deserialization, which does not read 
> configuration information from from the YAML file.
> This prevents deserialization of custom bytecode, such as references to a 
> custom Predicate class.



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

[jira] [Commented] (TINKERPOP-1578) Support writable distributed graphs using spark as the underlying engine

[Dovid Kopel (JIRA)]

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

Dovid Kopel commented on TINKERPOP-1578:


The changes I made didn't affect the `GraphComputer`...can you explain what you 
mean?

> Support writable distributed graphs using spark as the underlying engine
> 
>
> Key: TINKERPOP-1578
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1578
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dovid Kopel
>




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