[
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670376#comment-15670376
]
ASF GitHub Bot commented on TINKERPOP-1490:
-------------------------------------------
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/478
I like the bottom-up approach and a really quick turnaround!
Regarding the final API, given that it's an async flow designed for remote
operations (request/response), it would be nice to define clear boundaries,
making it easier to understand for the user what causes a remote execution.
Instead an all-purpose `promise()` API, it would be nice to have a
`toListAsync()` that returns a collection of
`Vertex`/`Edge`/`Path`/...disconnected elements instead of a `RemoteTraversal`.
Similar to `toListAsync()` we could expose an async method to get a single
result, something like `firstAsync()` or `oneAsync()`, that returns the
Vertices.
> 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)
