[GitHub] tinkerpop issue #448: Python glv graphson update

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
Hi -- one thing to add. I notice you changed `GraphSONWriter` and 
`GraphSONWriter` to `GraphSONIO` ... The writer/reader names are identical to 
Gremlin-Java. If its possible, can we leave the original class names? .. unless 
there is a strong pattern in Python that says that is bad. Thanks.


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

Code Freeze 3.2.3/3.1.5

[Stephen Mallette]

We're supposed to start code freeze tomorrow, but we are a little behind.
Still have one PR left to merge and it needs a rebase:

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

So expect that to get merged for 3.2.3 during code freeze week, but nothing
in that PR should preclude providers from testing their implementations.
Other than that, I think everything else of substance is in.

I do have one worry about that TraversalInterruption test that has been
failing randomly since the LazyBarrierStrategy stuff went in (i think).
Marko also mentioned the PeerPressure test. We'll put some elbow grease
into that next week and try to get those figured out and more stable.

As a reminder Ted will be release manager for 3.1.5 and I'll be doing
3.2.3. As usual, we will use this thread to coordinate during code freeze
week. Please bring up relevant issues here.

Thanks,

Stephen

[GitHub] tinkerpop issue #448: Python glv graphson update

[spmallette]

Github user spmallette commented on the issue:

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


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

[jira] [Commented] (TINKERPOP-1044) ResponseMessage should contain server-side exception name.

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> ResponseMessage should contain server-side exception name.
> --
>
> Key: TINKERPOP-1044
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1044
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.0-incubating
>Reporter: Bob Briody
>Priority: Minor
>
> When an exception occurs during execution by gremlin server, the 
> ResponseMessage currently contains the Exception message, but it would also 
> be helpful to include the Exception class name.



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

[GitHub] tinkerpop pull request #440: TINKERPOP-1044: Gremlin server REST endpoint - ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1458) Gremlin Server doesn't return confirmation upon Traversal OpProcessor "close" op

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

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


> Gremlin Server doesn't return confirmation upon Traversal OpProcessor "close" 
> op
> 
>
> Key: TINKERPOP-1458
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1458
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.2.2
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.2.3
>
>
> Gremlin Server should return some sort of success message to driver upon 
> invalidating the side effect cache for a traversal.



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

[GitHub] tinkerpop issue #451: TINKERPOP-1458 Gremlin Server doesn't return confirmat...

[okram]

Github user okram commented on the issue:

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


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

[jira] [Commented] (TINKERPOP-1458) Gremlin Server doesn't return confirmation upon Traversal OpProcessor "close" op

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/tinkerpop/pull/451#discussion_r82480587
  
--- Diff: 
gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/remote/DriverRemoteTraversalSideEffects.java
 ---
@@ -28,23 +28,27 @@
 
 import java.util.Collections;
 import java.util.HashMap;
+import java.util.HashSet;
 import java.util.Map;
 import java.util.Set;
 import java.util.UUID;
 import java.util.stream.Collectors;
 
 /**
  * @author Stephen Mallette (http://stephen.genoprime.com)
+ * This class is not thread safe.
--- End diff --

this line should go above the author line, but i'll do that after merge. 
not a big deal


> Gremlin Server doesn't return confirmation upon Traversal OpProcessor "close" 
> op
> 
>
> Key: TINKERPOP-1458
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1458
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.2.2
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.2.3
>
>
> Gremlin Server should return some sort of success message to driver upon 
> invalidating the side effect cache for a traversal.



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

[GitHub] tinkerpop pull request #451: TINKERPOP-1458 Gremlin Server doesn't return co...

[spmallette]

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

https://github.com/apache/tinkerpop/pull/451#discussion_r82480587
  
--- Diff: 
gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/remote/DriverRemoteTraversalSideEffects.java
 ---
@@ -28,23 +28,27 @@
 
 import java.util.Collections;
 import java.util.HashMap;
+import java.util.HashSet;
 import java.util.Map;
 import java.util.Set;
 import java.util.UUID;
 import java.util.stream.Collectors;
 
 /**
  * @author Stephen Mallette (http://stephen.genoprime.com)
+ * This class is not thread safe.
--- End diff --

this line should go above the author line, but i'll do that after merge. 
not a big deal


---
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 #451: TINKERPOP-1458 Gremlin Server doesn't return confirmat...

[spmallette]

Github user spmallette commented on the issue:

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

VOTE +1


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

[jira] [Commented] (TINKERPOP-1458) Gremlin Server doesn't return confirmation upon Traversal OpProcessor "close" op

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

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

VOTE +1


> Gremlin Server doesn't return confirmation upon Traversal OpProcessor "close" 
> op
> 
>
> Key: TINKERPOP-1458
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1458
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.2.2
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.2.3
>
>
> Gremlin Server should return some sort of success message to driver upon 
> invalidating the side effect cache for a traversal.



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

Re: [DISCUSS] Test Suite Changes for 3.3.0

[Stephen Mallette]

Thought I'd keep this thread warm a bit. If you've built the TinkerPop repo
recently, you would realize it's taking a really long time these days to
get a simple `mvn clean install` completed. We've produced tons of tests
that are adding to build times and I think that while we have lots of
tests, it does NOT mean:

1. we need to execute all of them all of the time or that
2. we have good coverage

I think that we will need to start optimizing our unit test runs (and the
build in general) to get us back to a point where we can get a build in
less than 15 minutes (10 would be better, but I'm not sure we'll get there
as an initial step). Just from the test perspective, I think this will mean:

1. More unit tests that mock interfaces/classes over full stack integration
tests
2. Move more unit tests to integration tests

So with all that in mind, I've got a local branch that adds a -Dcoverage
option that does two things:

1. builds an aggregated report of unit test data to show us what's running
long
2. builds an aggregated test coverage report that shows us what code is
tested and what is not

So far this only is setup for unit tests (not integration tests) and it's
really just a model as I don't have hadoop/spark/giraph in the mix yet for
coverage. As I alluded to earlier in this thread, I was going to use jacoco
now that it supports java 8 and does a better job with multi-module builds.
It works fine but I had to create a gremlin-coverage module to make it all
work. That kinda stinks, so I opted instead to repurpose gremlin-benchmark
to hold the coverage configuration. It just means that gremlin-benchmark
would now have some additional dependencies and the new config for the
"coverage" maven profile. If everyone thinks that's ok, I will make this
part of 3.2.2. I don't think that infringes too much on gremlin-benchmark,
but that's just my opinion - to me that's better than yet another module.

Given that there's been no objections in this thread, I will likely create
some JIRA tickets based on what i've suggested here so that I can get to
work on that first thing for 3.3.0 (and try to speed up the 3.2.2 build
where possible).


On Tue, Sep 20, 2016 at 11:16 AM, Stephen Mallette 
wrote:

> I think these are the ones that contain logic and are dynamically sorta
> driven:
>
> ElementFeatures.willAllowId(Object)
> VertexPropertyFeatures.willAllowId(Object)
> VertexFeatures.getCardinality(String)
>
> I was thinking that some graphs might return static values for these in
> which case caching would work. Obviously, schema driven graphs would have
> trouble with getCardinality(), though I don't remember the contexts in
> which any of these are used - my analysis didn't go that far.
>
>
> On Tue, Sep 20, 2016 at 10:54 AM, Jason Plurad  wrote:
>
>> Nice discussion thread, Stephen. I've tinkered around minimally with
>> writing a graph implementation, so hopefully we'll get more feedback from
>> others. From what I have done, +1 on killing @OptOut test annotations.
>> They
>> seem out of place on the Graph impl class.
>>
>> You mentioned "there is at least one method that could be called on
>> Features that is
>> typically dynamically driven based on schema" -- which method is that?
>>
>> -- Jason
>>
>> On Mon, Sep 19, 2016 at 4:33 PM, Stephen Mallette 
>> wrote:
>>
>> > I've spent the middle portion of the day reviewing our test
>> infrastructure
>> > and related open tickets and have some ideas to make some things
>> better. I
>> > titled this post for 3.3.0, but, in truth, I'm not sure what must be
>> 3.3.0
>> > and what might yet be useful and good for 3.2.x. I'm also using this
>> email
>> > as a way to organize my notes/ideas from the day, so apologies if I'm
>> > dumping a lot of stuff here to follow.
>> >
>> > (1) Of all the things I came up with, I think the biggest breaker is
>> this
>> > one: have one uber test suite in gremlin-test. In other words, merge
>> > gremlin-groovy-test to gremlin-test and get rid of that all together.
>> Then.
>> > stop publishing test artifacts out of hadoop-gremlin (and wherever else
>> we
>> > might be doing that). We can make groovy and hadoop dependencies
>> optional
>> > so that if providers aren't using them, they don't have to have them
>> sucked
>> > in and can just depend on them as needed.
>> >
>> > (2) Next biggest breaker - how does everyone feel about killing OptOut
>> and
>> > OptIn and getting those concepts out of gremlin-core and into features
>> of
>> > gremlin-test. I've heard at least two Graph providers mention a problem
>> > where they want to "OptOut" more at the GraphProvider level as opposed
>> to
>> > the Graph level as their configurations in the GraphProvider do more to
>> > drive that setting than the Graph does. I don't think we lose anything
>> by
>> > moving "OptOut" except for the describeGraph() functionality:
>> >
>> > 

[GitHub] tinkerpop issue #448: Python glv graphson update

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
I like these changes. With a solid rebase of master/ given my recent 
`TraversalStrategy` serializer work, I'm good with merging this PR.

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 #448: Python glv graphson update

[davebshow]

Github user davebshow commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
Yeah makes sense. I'm hoping to do some major refactors of the Driver over 
the next couple months anyway, but I'm juggling too many things right now. 
Either way this seems good to go.


---
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 #448: Python glv graphson update

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
@aholmberg I know. Sorry. I'm not graceful.


---
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 #448: Python glv graphson update

[aholmberg]

Github user aholmberg commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
argh. needs a third rebase, too :-/


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

[GitHub] tinkerpop issue #448: Python glv graphson update

[aholmberg]

Github user aholmberg commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
> graphson_io=None to the __init__ method signature

I think that is a fine idea. I was mostly focused on the GraphSON API and 
not concerned with adding it to the token RemoteConnection implementation 
(figuring it would get pulled in if someone saw cause to do it).
If you think it's worth doing now (and it won't invalidate this vote), I 
can push the update I have here.


---
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 #451: TINKERPOP-1458 Gremlin Server doesn't return confirmat...

[davebshow]

Github user davebshow commented on the issue:

https://github.com/apache/tinkerpop/pull/451
  
Alright I think this branch is ready to go. 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.
---

The Beauty of Bulking -- Redux'prise

[Marko Rodriguez]

Hello,

Many moons ago, I wrote an email to this list called “The Beauty of Bulking” 
which discussed the concept of traverser bulking.

This notion is perhaps the most important aspect of the Gremlin traversal 
machine. It is what makes OLAP scale, speedy complex path-calculations 
plausible, and runtimes on reverberant traversals extremely fast.

Bulking can be summed up easily:

1. If you have a stream of numbers, say [6, 5, 4, 4, 4, 6] you can map() those 
numbers by *10 and thus do 6 arithmetic operations to yield [60, 50, 40, 40, 
40, 60].
2. However, if stream ordering does not matter (an important constraint to 
lift!), then you could get the “same” result with only 3 arithmetic operations 
and yield [60, 60, 50, 40, 40, 40].
3. In short, “bulk” your objects — 6(2), 5(1), 4(3). Then you only need to 
execute *10 three times.

Prior to this moment, the beauty of bulking has made itself apparent in every 
OLAP job executed as well as in repeat(), barrier(), and the epic work from Ted 
Wilmes on PathRetractionStrategy.

Kuppitz and I are adding to this subtle beauty with a rewrite of 
LazyBarrierStrategy and its inclusion into the default TraversalStrategies that 
are inherited (typically) by all graph system providers.

Lets look at what we have done to master/ and what you can expect in TinkerPop 
3.2.3.

graph = TinkerGraph.open()
graph.io(gryo()).readGraph('data/grateful-dead.kryo')
g1 = graph.traversal().withoutStrategies(LazyBarrierStrategy.class)
g2 = graph.traversal()

From g1 (no beauty) and g2 (beautiful), lets see how various traversals perform.

gremlin> clock(10){g1.V().out().in().out().count().iterate()}
==>1073.515044999
gremlin> clock(10){g2.V().out().in().out().count().iterate()}
==>8.8109061

Deep traversals with lots of intersections do the best. A 1 second query is 
dropped to 8 milliseconds. Thats a 100x+ speed improvement.

gremlin> clock(1000){g1.V().out().values('name').iterate()}
==>1.139402673998
gremlin> clock(1000){g2.V().out().values('name').iterate()}
==>1.030407659

Not that much intersection above, but we still get a little bump in performance.

**DRUM ROLL — THE PHOENIX RISES FROM THE TEXTS OF EDFU**

Lets get practical. 

Graph analysis is all about “reverberation.” What does that mean? — look at any 
graph algorithm. Its not about just “getting data," its about seeing how paths 
intersect/overlay/loop amongst themselves and each other. Paths tell you a lot 
about the “structure” of your data — topological statistics. PageRank, 
Betweenness, Eccentricity, Eigenvectors, Recommendations, Spreading Activation, 
…. these algorithms are all about the paths, not “the data." Lets look at a 
classic Amazon.com -style recommendation algorithm:

“Person ‘a' likes X. X are liked by people B. People B like Y. 
Recommend ‘a’ items from Y that are not in X.”

g.V(89).out('followedBy').aggregate('a').
  in('followedBy').out(‘followedBy').
where(not(within('a'))).
  groupCount().by('name')

Okay. So lets do that walk on our toy graph, where Person ‘a’ is v[89].

gremlin> 
clock(100){g1.V(89).out('followedBy').aggregate('a').in('followedBy').out('followedBy').where(not(within('a'))).groupCount().by('name').iterate()}
==>23.73006225
gremlin> 
clock(100){g2.V(89).out('followedBy').aggregate('a').in('followedBy').out('followedBy').where(not(within('a'))).groupCount().by('name').iterate()}
==>1.44107251

So there you have it. The classic, “everyone and their mother does 
it”-traversal went from 23ms to 1.4ms. A 20x performance improvement on a 
practical everyday example.

gremlin> 
g2.V(89).out('followedBy').aggregate('a').in('followedBy').out('followedBy').where(not(within('a'))).groupCount().by('name').explain()
==>Traversal Explanation

Original Traversal [GraphStep(vertex,[89]), 
VertexStep(OUT,[followedBy],vertex), AggregateStep(a), 
VertexStep(IN,[followedBy],vertex), VertexStep(OUT,[followedBy],vertex), 
WherePredicateStep(without([a])), GroupCountStep(value(name))]
...
LazyBarrierStrategy  [O]   [GraphStep(vertex,[89]), 
VertexStep(OUT,[followedBy],vertex), AggregateStep(a), 
VertexStep(IN,[followedBy],vertex), NoOpBarrierStep(1), 
VertexStep(OUT,[followedBy],vertex), NoOpBarrierStep(1), 
WherePredicateStep(without([a])), GroupCountStep(value(name))]
...
Final Traversal[TinkerGraphStep(vertex,[89]), 
VertexStep(OUT,[followedBy],vertex), AggregateStep(a), 
VertexStep(IN,[followedBy],vertex), NoOpBarrierStep(1), 
VertexStep(OUT,[followedBy],vertex), NoOpBarrierStep(1), 
WherePredicateStep(without([a])), GroupCountStep(value(name))]

Word to your mutha,
Marko.

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

[Marko A. Rodriguez (JIRA)]

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

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

There are numerous "action/terminal"-methods off of {{Traversal}}.

* {{next()}}
* {{hasNext()}}
* {{nextTraverser()}}
* {{toList()}}
* {{toSet()}}
* {{iterate()}}
* {{explain()}}
* ...

If we want asyncrhonous support for all terminal methods, then I think we 
shouldn't go down the route of {{nextAsync()}}, {{toListAsync()}}, etc. That is 
a bit dirty. Instead, I think we should have one method --- call it what we 
want --- that is basically a "future" that takes a {{Function}}. 
Thus, we can do:

{code}
g.V().out().future(Traversal::toList)
g.V().out().future(Traversal::next)
...
{code}

In Java, its called a {{Future}}. Moreover, you can do {{CompletableFutures}} 
(https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html).
 Thus, I think we kill many birds with one stone here. We get "async" and 
"callback" support using one (and only one) method. Lets call it 
{{Traversal.future()}} given the status of the term "async." Thus, I propose 
that we add:

{code}
Future Traversal.future(Function)
{code}

Lets get more specific and allow both "async" and "callback" via 
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/FutureTask.html.

{code}
OurFuture Traversal.future(Function)
void OurFuture.then(Consume)
{code}

...where {{OurFuture}} will be a custom class based off of {{FutureTask}}. In 
sum total, you would then be able to do two things:

{code}
OurFuture result = 
g.V().out().values("name").future(Traversal::List)
// some other stuff in parallel
List list = result.get()
{code}

...and

{code}
g.V().out().values("name").future(Traversal::List).then(names -> 
System.out.println("Here are the names of everyone: " + names))
// some other stuff in parallel
{code}

Both async and callback support across all terminal {{Traversal}} methods.

*** NOTE: I'm not married to {{future}} and {{then}} method names...so 
whateves. 

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