[ https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654950#comment-15654950 ]
ASF GitHub Bot commented on TINKERPOP-1490: ------------------------------------------- Github user davebshow commented on the issue: https://github.com/apache/tinkerpop/pull/478 After actually thinking about this, the type of future returned will depend on the underlying `RemoteConnection` implementation. A call to the method`promise` will cause a `(async)traversal_strategy` to call `apply`, the result of this depends on the underlying remote connection, and all the GLV has to do is pass the returned futures along to the end user. Therefore a Tornado based driver would return a `tornado.concurrent.Future` etc. etc. Make sense? Or am I missing something...? > Provider a Future based Traversal.async(Function<Traversal,V>) 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<List<String>> result = > g.V().out().values("name").async(Traversal::toList) > {code} > {code} > Future<List<String>> 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)