Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/478
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 f
Github user davebshow commented on the issue:
https://github.com/apache/tinkerpop/pull/478
Tests pass. I think this is a good base to move forward to a fully
functional async API for Gremlin.
VOTE +1
---
If your project is set up for it, you can reply to this email and have
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 proj
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 w
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
Github user davebshow commented on the issue:
https://github.com/apache/tinkerpop/pull/478
As long as the driver returns a future with a compatible API, yes, it can
be used with all Python versions. The snippet you provided will throw an error
with an Asyncio or Tornado client, as you
Github user aboudreault commented on the issue:
https://github.com/apache/tinkerpop/pull/478
Except my initial concern, can you confirm we can use the latest way with
all Python versions and with/without a custom driver? It would be nice to have
an unified way that just works everywhe
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/478
It's been about a week since @davebshow laid out the approach he's
recommending here. I assume the silence means that there are no objections to
that approach and we have consensus on what to d
Github user davebshow commented on the issue:
https://github.com/apache/tinkerpop/pull/478
I put together a quick example of how this can be implemented in
gremlin-python. Obviously the example is incomplete, but hopefully it can help
move the discussion forward:
https://github.com/a
Github user davebshow commented on the issue:
https://github.com/apache/tinkerpop/pull/478
I agree with the `RemoteConnection` implementation being pluggable.
Therefore, the GLV should be able to use any remote connection as long as it
complies with the API. But, since pre-Python3 doe
Github user aboudreault commented on the issue:
https://github.com/apache/tinkerpop/pull/478
@davebshow @aholmberg (PYTHON) I must agree that my initial thought is that
we should try to avoid the coupling with tornado. However, since tornado is
already used internally, it might get be
Github user newkek commented on the issue:
https://github.com/apache/tinkerpop/pull/478
I think the `promise()` method is more elegant as well, as it avoids adding
many new methods in the Traversal API
---
If your project is set up for it, you can reply to this email and have your
re
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/478
I think I agree with @okram for now that we not add a lot of methods just
yet. It's easy to add methods, but harder to take them away later. Let's be
sure this gets used in the fashion we expec
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
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/478
I ran about 50 million messages through Gremlin Server over the weekend and
didn't see any problems as a result of my changes here. I think this seems
pretty solid now. I'd quietly asked both @
Github user davebshow commented on the issue:
https://github.com/apache/tinkerpop/pull/478
@aholmberg I'm not sure if I follow...it seems to me that if a
`RemoteConnection` implementation returns a list (or future list ) of
`FutureTraversers`, the traversal API can still remain indepe
Github user aholmberg commented on the issue:
https://github.com/apache/tinkerpop/pull/478
> the type of future returned will depend on the underlying
RemoteConnection implementation.
That depends on whether you are okay leaking remote connection
implementation through this A
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_str
Github user aholmberg commented on the issue:
https://github.com/apache/tinkerpop/pull/478
Coupling the traversal API to a web framework does not seem appealing to
me. Could we consider using the [futures
backport](https://pypi.python.org/pypi/futures), which backports the Python 3
s
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/478
thanks @davebshow - i might ask for your assistance on implementing that.
still trying to get it right for java. that blocking call in `RemoteStep`
stinks. having a bit of a hard time
Github user davebshow commented on the issue:
https://github.com/apache/tinkerpop/pull/478
@spmallette you can easily implement something similar in Python using
Futures. Using `tornado.concurrent.Future` would probably make the most sense,
as is is already 2/3 compatible and should w
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/478
> The thread pool is still needed at some point though, since executing
against a local TinkerGraph is currently done in the same thread
agreed - and that's where i was getting confused
Github user newkek commented on the issue:
https://github.com/apache/tinkerpop/pull/478
The issue with using a secondary thread pool that will start a new thread
for each Traversal execution would be more important when the Traversal is
backed by a RemoteConnection. Where each Travers
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/478
> What makes `toListAsync()` more "fully async" compared to
`promise(traversal::toList)`? Internally, from a Java perspective anyway,
`toListAsync()` does the same thing, doesn't it?
By
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/478
> CoreTraversalTest is that it uses mutating steps and thus, not subject to
OLAP testing
Ah - didn't think to check if that was fully ignored. I'll fix that up.
---
If your project is
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/478
The problem with the `CoreTraversalTest` is that it uses mutating steps and
thus, not subject to OLAP testing. I would simply create a `PromiseTest` just
like `ExplainTest` and have a few traversals
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/478
> I think that, instead of doing blocking calls like fn.apply() on a thread
pool, we could expose a fully async API. Something like toListAsync() that
returns a CompletableFuture>.
Cou
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/478
> Why do you ignore promise tests for GroovyTranslator and JavaTranslator.
Seems we would want that to work as well.
I thought I was getting errors because of the lambda i use to simula
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/478
I think that, instead of doing blocking calls like `fn.apply()` on a thread
pool, we could expose a fully async API. Something like `toListAsync()` that
returns a `CompletableFuture>`.
F
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/478
Wow. This is cool. Questions/comments:
1. Why do you ignore promise tests for `GroovyTranslator` and
`JavaTranslator`. Seems we would want that to work as well.
2. Why not have a `Promis
30 matches
Mail list logo
