[GitHub] tinkerpop pull request #451: TINKERPOP-1458 Gremlin Server doesn't return co...
Github user davebshow closed the pull request at: https://github.com/apache/tinkerpop/pull/451 --- 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
[ https://issues.apache.org/jira/browse/TINKERPOP-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15558368#comment-15558368 ] ASF GitHub Bot commented on TINKERPOP-1458: --- Github user davebshow closed the pull request at: https://github.com/apache/tinkerpop/pull/451 > 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...
Github user davebshow commented on the issue: https://github.com/apache/tinkerpop/pull/451 Manually closing post merge. --- 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
[ https://issues.apache.org/jira/browse/TINKERPOP-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15558367#comment-15558367 ] ASF GitHub Bot commented on TINKERPOP-1458: --- Github user davebshow commented on the issue: https://github.com/apache/tinkerpop/pull/451 Manually closing post merge. > 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)
[jira] [Commented] (TINKERPOP-1458) Gremlin Server doesn't return confirmation upon Traversal OpProcessor "close" op
[ https://issues.apache.org/jira/browse/TINKERPOP-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15558351#comment-15558351 ] ASF GitHub Bot commented on TINKERPOP-1458: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/451 yeah - will figure it out next week - it's this nonsense: ```text TraversalInterruptionTest.shouldRespectThreadInterruptionInVertexStep:111 Expected: is but: was TraversalInterruptionTest.shouldRespectThreadInterruptionInVertexStep:111 Expected: is but: was ``` i mentioned it in the "code freeze" post to dev list. not related to this PR (which is already merged btw - @davebshow needs to close it on his end because i flubbed the merge a little bit and rebased after some conflicts on master) > 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...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/451 yeah - will figure it out next week - it's this nonsense: ```text TraversalInterruptionTest.shouldRespectThreadInterruptionInVertexStep:111 Expected: is but: was TraversalInterruptionTest.shouldRespectThreadInterruptionInVertexStep:111 Expected: is but: was ``` i mentioned it in the "code freeze" post to dev list. not related to this PR (which is already merged btw - @davebshow needs to close it on his end because i flubbed the merge a little bit and rebased after some conflicts on master) --- 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...
Github user PommeVerte commented on the issue: https://github.com/apache/tinkerpop/pull/451 Hmm do we know why's travis is choking? --- 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
[ https://issues.apache.org/jira/browse/TINKERPOP-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15558320#comment-15558320 ] ASF GitHub Bot commented on TINKERPOP-1458: --- Github user PommeVerte commented on the issue: https://github.com/apache/tinkerpop/pull/451 Hmm do we know why's travis is choking? > 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
yeah - i actually thought about "gremlin-tools" and almost wondered if we shouldn't do: gremlin-tools +-gremlin-benchmarks +-gremlin-coverage for 3.3.0. The added flexibility to have independent poms for these things might turn out useful. I sorta like that idea. On Sat, Oct 8, 2016 at 10:47 AM, Ted Wilmes wrote: > Adding coverage to gremlin-benchmark sounds good to me. If we come up with > any other dev specific tooling that we'd like to add, maybe it would make > sense > to just rename gremlin-benchmark to something like gremlin-tools or > gremlin-dev. > > --Ted > > On Fri, Oct 7, 2016 at 5:20 PM, Stephen Mallette > wrote: > > > 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 < > spmalle...@gmail.com > > > > > >> 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 > > >
Re: [DISCUSS] Test Suite Changes for 3.3.0
Adding coverage to gremlin-benchmark sounds good to me. If we come up with any other dev specific tooling that we'd like to add, maybe it would make sense to just rename gremlin-benchmark to something like gremlin-tools or gremlin-dev. --Ted On Fri, Oct 7, 2016 at 5:20 PM, Stephen Mallette wrote: > 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 > >> > g
Re: [DISCUSS] ASF Board Draft Report - October 2016
The October 2016 board report has been submitted. On Tue, Oct 4, 2016 at 11:16 AM, Dylan Millikin wrote: > Yeah looking great! > > On Tue, Oct 4, 2016 at 10:39 AM, Marko Rodriguez > wrote: > > > Diamn — that is one solid report. > > > > Marko. > > > > http://markorodriguez.com > > > > > > > > > On Oct 4, 2016, at 8:36 AM, Stephen Mallette > > wrote: > > > > > > A lot of stuff seems to have happened since our last report - did I > miss > > > anything? > > > > > > > > -- > > > > > > ## Description: > > > Apache TinkerPop is a graph computing framework for both graph > databases > > > (OLTP) and graph analytic systems (OLAP). > > > > > > ## Activity: > > > TinkerPop has added a new member to the PMC in Jason Plurad and a new > > > committer in David Brown. > > > > > > TinkerPop released 3.1.4 and 3.2.2. 3.2.2 contains gremlin-python[1], > > > which > > > officially opens TinkerPop up to the Python community. We tend to think > > > of Python as the most used language for TinkerPop outside of the JVM so > > > having native support for it should help expand usage. October will see > > > releases 3.1.5 and 3.2.3. These two releases are mostly bug fixes and > > > minor > > > usability improvements. We expect to continue to maintain both of these > > > lines of code (bug fixes for 3.1.4 and ongoing development of 3.2.2), > but > > > intend to begin work on a new major line in 3.3.0 in the coming weeks. > > > > > > In an effort to share the technical knowledge of "releasing TinkerPop", > > > we've > > > started to share the work of that process. While we've always had our > > > release > > > process documented[2] and a single release manager can handle releases, > > > we've determined it better (when possible) to have one release manager > > per > > > release line. Our initial trial with one release manager per version, > on > > > the > > > previous release, worked well. We hope to continue with this approach > for > > > future releases. > > > > > > Promotionally speaking, there have been a number of talks at > conferences > > > on, > > > or related, to TinkerPop. As a sample, here are the talks given by PMC > > > members: > > > > > > Graph Computing with Apache TinkerPop - Dr. Marko Rodriguez [3] > > > Graph Processing with Titan and Scylla - Jason Plurad [4] > > > > > > On the brand management front, it was noted by a PMC member (Jason > Plurad > > > had just been voted in almost to the day he made the report) that there > > > was > > > an individual selling products (baby clothes, mugs, t-shirts, etc.) on > > > Amazon > > > with TinkerPop graphics on them. Soon after, a second company was also > > > noted > > > selling similar products on an independent site. Neither, had > permission > > > from > > > Apache to do that. After some discussion with Trademarks, the PMC chair > > > sent > > > notice to both sites requesting that they acknowledge the marks in > their > > > product description. No response was received from the seller on > Amazon, > > > but > > > all products were quickly removed. No response was received from the > > second > > > seller, but on greater inspection of the site, it doesn't really appear > > to > > > be > > > terribly active or maintained. Next steps with respect to this seller > > have > > > yet to be discussed. > > > > > > ## Issues: > > > There are no issues requiring board attention at this time. > > > > > > ## Releases: > > > - 3.1.4 (September 6, 2016) > > > - 3.2.2 (September 6, 2016) > > > > > > ## PMC/Committer: > > > > > > - Last PMC addition was Jason Plurad - August 2016 > > > - Last committer addition was David Brown - August 2016 > > > > > > ## Links > > > > > > [1] http://tinkerpop.apache.org/docs/current/reference/#gremlin-python > > > [2] http://tinkerpop.apache.org/docs/current/dev/developer/#_ > > release_process > > > [3] https://www.youtube.com/watch?v=tLR-I53Gl9g > > > [4] https://www.youtube.com/watch?v=RllAy9OjzIo > > > > >
Re: [DISCUSS] Traversal Future
I would draw the line at the native language's understanding of future/promise, which are generally represented in most languages i'm aware of. The specifics of CompletableFuture do not have to be maintained. I suppose we could consider it sugar specific to the GLV.not sure one way or the other right now. On Sat, Oct 8, 2016 at 8:39 AM, Robert Dale wrote: > I think it's outside of gremlin's scope and may be better served by > native facilities. It seems like sugar. In Java this saves not even > one line of code. It looks an additional requirement for GLVs to > implement possibly using a syntax that is non-native thus additional > to learn. But the GLV folks will have to speak to that. Even if so, > where do you draw the line? Until you've reimplemented all of > CompletableFuture? I already use java's and spring's async > facilities so I would not likely use this. > > On Sat, Oct 8, 2016 at 7:08 AM, Stephen Mallette > wrote: > > Please note the discussion on adding a terminal future method to > Traversal > > on this JIRA ticket: > > > > https://issues.apache.org/jira/browse/TINKERPOP-1490 > > > > If you have comments, please add them there. > > > > -- > Robert Dale >
Re: [DISCUSS] Traversal Future
I think it's outside of gremlin's scope and may be better served by native facilities. It seems like sugar. In Java this saves not even one line of code. It looks an additional requirement for GLVs to implement possibly using a syntax that is non-native thus additional to learn. But the GLV folks will have to speak to that. Even if so, where do you draw the line? Until you've reimplemented all of CompletableFuture? I already use java's and spring's async facilities so I would not likely use this. On Sat, Oct 8, 2016 at 7:08 AM, Stephen Mallette wrote: > Please note the discussion on adding a terminal future method to Traversal > on this JIRA ticket: > > https://issues.apache.org/jira/browse/TINKERPOP-1490 > > If you have comments, please add them there. -- Robert Dale
[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant
[ https://issues.apache.org/jira/browse/TINKERPOP-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15557844#comment-15557844 ] ASF GitHub Bot commented on TINKERPOP-1489: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/450 ha +1 for a promise style api - i just wrote the exact same suggestion for the java side: https://issues.apache.org/jira/browse/TINKERPOP-1490?focusedCommentId=15557840&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15557840 > Provide a Javascript Gremlin Language Variant > - > > Key: TINKERPOP-1489 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1489 > Project: TinkerPop > Issue Type: Improvement > Components: language-variant >Reporter: Jorge Bay > > It would be nice to have a Javascript Gremlin Language Variant that could > work with any ES5 runtime, specially the ones that support > [CommonJs|http://requirejs.org/docs/commonjs.html], like Node.js. > Nashorn, the engine shipped with JDK 8+, does not implement CommonJs but > provides [additional > extensions|https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions] > making modular JavaScript possible. Nashorn should be supported in order to > run glv tests under the same infrastructure (JDK8). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TINKERPOP-1490) Provider a Future based Traversal.async(Function) terminal step
[
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15557840#comment-15557840
]
stephen mallette edited comment on TINKERPOP-1490 at 10/8/16 11:54 AM:
---
{{future}} with an extension of {{FutureTask}} seems good to me, though i don't
think we should ignore {{CompletableFuture}}. {{Traversal}} should have:
{code}
void promise(CompletableFuture future) // perhaps we just start a thread to
iterate the traversal (i.e no thread pool)
void promise(CompletableFuture future, ExecutorService executor) // in this
case we provide a thread pool to execute in
{code}
{{CompletableFuture}} provides a lot more flexibility for handling exceptions,
starting async tasks in different executors, and clarifies situations with lots
of callback chaining. It makes it trivial to do stuff like:
{code}
promiseOutNames = new CompletableFuture()
promiseInNames = new CompletableFuture().thenAccept(f -> transformResult(f))
promiseBothNames = promiseInNames.thenCombine(promiseOutNames, (in,out) ->
combineInOut(in, out)).
thenRunAsync(f
-> notifySomethingOfBoth(f), gremlinServerExecutorService)
g.V(1).out().values("name").promise(promise1)
g.V(1).in().values("name").promise(promise2)
{code}
So the above would traverse in/out vertices in parallel across two separate
threads, combine the results and then make an async call to notify some service
about the combined results.
was (Author: spmallette):
{{future}} with an extension of {{FutureTask}} seems good to me, though i don't
think we should ignore {{CompletableFuture}}. {{Traversal}} should have:
{code}
void promise(CompletableFuture future) // in this case, perhaps we just start
a thread to iterate the traversal in gremlinServerExecutorService (i.e no
thread pool)
void promise(CompletableFuture future, ExecutorService executor) // in this
case we provide a thread pool to execute in
{code}
{{CompletableFuture}} provides a lot more flexibility for handling exceptions,
starting async tasks in different executors, and clarifies situations with lots
of callback chaining. It makes it trivial to do stuff like:
{code}
promiseOutNames = new CompletableFuture()
promiseInNames = new CompletableFuture().thenAccept(f -> transformResult(f))
promiseBothNames = promiseInNames.thenCombine(promiseOutNames, (in,out) ->
combineInOut(in, out)).
thenRunAsync(f
-> notifySomethingOfBoth(f), gremlinServerExecutorService)
g.V(1).out().values("name").promise(promise1)
g.V(1).in().values("name").promise(promise2)
{code}
So the above would traverse in/out vertices in parallel across two separate
threads, combine the results and then make an async call to notify some service
about the combined results.
> 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 #450: TINKERPOP-1489 Javascript GLV
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/450 ha +1 for a promise style api - i just wrote the exact same suggestion for the java side: https://issues.apache.org/jira/browse/TINKERPOP-1490?focusedCommentId=15557840&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15557840 --- 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-1489) Provide a Javascript Gremlin Language Variant
[
https://issues.apache.org/jira/browse/TINKERPOP-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15557838#comment-15557838
]
ASF GitHub Bot commented on TINKERPOP-1489:
---
Github user jbmusso commented on the issue:
https://github.com/apache/tinkerpop/pull/450
I was thinking that supporting JavaScript `Promise` could be helpful now
that they’ve been part of the ES2015 and rolled out on most JS environment
(browsers/Node.js). Maybe this can be polyfilled under Nashorn? Using `Promise`
could complement Node.js style async functions with a callback passed as last
parameter (functions with such signature can be easily converted to functions
returning a Promise [with many third-party Promise libraries such as
Bluebird](http://bluebirdjs.com/docs/api/promise.promisify.html)). This way, a
`Traversal` could be ended with something like `.toPromise()`. I think the
following makes a lot of sense in JavaScript since it’s part of the standard:
```javascript
// JavaScript
g.V().out('created').toPromise()
.then(function (vertices) {
// do something with results
})
.catch(function (err) {
// handle error
})
.finally(function () {
// cleanup
});
// Alternatively, the end user could use use a promisifying function over
.toList():
g.V().out('created').toListAsync()
.then()
.catch();
```
Coming soon to the standard are `async` functions which return a `Promise`,
so you could do this:
```javascript
// JavaScript
async function followers() {
try {
const followers = await g.V().in('followers').toPromise();
} catch(e) {
// Handle error
}
}
```
There also are `Observable` (think: `Promise` with multiple return values,
or `Array` but laid out over time rather than in memory) that are worth
considering in JavaScript. Observable are candidate for being part of the
standard. Libraries such as RxJS v5, which aims to be spec. compliant, works
wonderfully. That way, we could also have `.toObservable()` in JavaScript:
```javascript
// JavaScript
g.V().out('created').toObservable()
.subscribe(
function (vertex) {
// This gets called once for each vertex
},
function (err) {
// Handle errors
},
function () {
// Called when observable ends (ie. after last vertex is emitted)
}
)
```
I took a different path in Node.js and started developing
[zer](https://github.com/jbmusso/zer) (short for seriali**zer**), a generic
"JavaScript-to-anything" library that uses the ES2015 Proxy object. The lib
builds an AST-ish (I'm learning these :P) which can output to anything,
including Gremlin-Groovy (currently) and most likely Gremlin-bytcode easily (it
could also output to SQL or Cypher, but hey). The trick is to `Proxy()`ify a
`Function` (rather than an `Object`) and intercept calls to that function with
`Proxy.apply()` and mutation of that function properties with `Proxy.get()`
(you can do both since functions are objects in JavaScript).
The `zer` lib allows generating queries such as
`g.V().out().in().bla().method().not().in().tinkerpop().source().code()`
(Grooovy output) but it could easily support things like
`select().from().where()` (and produce SQL-output). Coding the gremlin-bytecode
output should be trivial. It also supports nested traversals and automatic
escaping of bound parameters (it basically escapes all primitives and anything
that is not a `Traversal`). I think it could also support serializing
functions/lambdas since you can do `Function.toString()` in JavaScript and
extract the function body at runtime.
I don’t think that the Proxy approach can work in Nashorn since Proxy can’t
be emulated in ES5 environment (it only works in Node v6 I recall, maybe Node
v5). However, in Node.js, I think I would just use Proxy objects that can
intercept anything - I think generating code might not be worth it there. I
think this PR is valid in Nashorn but I'm unsure about Node.js.
Note that `zer` and `gremlin-javascript` are distinct libraries. Once
stable enough, `zer` (with just Gremlin-Groovy and Gremlin-Bytecode output)
could be added as a dependency to `gremlin-javascript`.
> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant
>Reporter: Jorge Bay
>
> It would be nice to have a Javascript Gremlin Language Variant that could
> work with any ES5 runtime, specially the ones that support
> [CommonJs|http://requirejs.org/
[jira] [Commented] (TINKERPOP-1490) Provider a Future based Traversal.async(Function) terminal step
[
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15557840#comment-15557840
]
stephen mallette commented on TINKERPOP-1490:
-
{{future}} with an extension of {{FutureTask}} seems good to me, though i don't
think we should ignore {{CompletableFuture}}. {{Traversal}} should have:
{code}
void promise(CompletableFuture future) // in this case, perhaps we just start
a thread to iterate the traversal in gremlinServerExecutorService (i.e no
thread pool)
void promise(CompletableFuture future, ExecutorService executor) // in this
case we provide a thread pool to execute in
{code}
{{CompletableFuture}} provides a lot more flexibility for handling exceptions,
starting async tasks in different executors, and clarifies situations with lots
of callback chaining. It makes it trivial to do stuff like:
{code}
promiseOutNames = new CompletableFuture()
promiseInNames = new CompletableFuture().thenAccept(f -> transformResult(f))
promiseBothNames = promiseInNames.thenCombine(promiseOutNames, (in,out) ->
combineInOut(in, out)).
thenRunAsync(f
-> notifySomethingOfBoth(f), gremlinServerExecutorService)
g.V(1).out().values("name").promise(promise1)
g.V(1).in().values("name").promise(promise2)
{code}
So the above would traverse in/out vertices in parallel across two separate
threads, combine the results and then make an async call to notify some service
about the combined results.
> 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 #450: TINKERPOP-1489 Javascript GLV
Github user jbmusso commented on the issue:
https://github.com/apache/tinkerpop/pull/450
I was thinking that supporting JavaScript `Promise` could be helpful now
that theyâve been part of the ES2015 and rolled out on most JS environment
(browsers/Node.js). Maybe this can be polyfilled under Nashorn? Using `Promise`
could complement Node.js style async functions with a callback passed as last
parameter (functions with such signature can be easily converted to functions
returning a Promise [with many third-party Promise libraries such as
Bluebird](http://bluebirdjs.com/docs/api/promise.promisify.html)). This way, a
`Traversal` could be ended with something like `.toPromise()`. I think the
following makes a lot of sense in JavaScript since itâs part of the standard:
```javascript
// JavaScript
g.V().out('created').toPromise()
.then(function (vertices) {
// do something with results
})
.catch(function (err) {
// handle error
})
.finally(function () {
// cleanup
});
// Alternatively, the end user could use use a promisifying function over
.toList():
g.V().out('created').toListAsync()
.then()
.catch();
```
Coming soon to the standard are `async` functions which return a `Promise`,
so you could do this:
```javascript
// JavaScript
async function followers() {
try {
const followers = await g.V().in('followers').toPromise();
} catch(e) {
// Handle error
}
}
```
There also are `Observable` (think: `Promise` with multiple return values,
or `Array` but laid out over time rather than in memory) that are worth
considering in JavaScript. Observable are candidate for being part of the
standard. Libraries such as RxJS v5, which aims to be spec. compliant, works
wonderfully. That way, we could also have `.toObservable()` in JavaScript:
```javascript
// JavaScript
g.V().out('created').toObservable()
.subscribe(
function (vertex) {
// This gets called once for each vertex
},
function (err) {
// Handle errors
},
function () {
// Called when observable ends (ie. after last vertex is emitted)
}
)
```
I took a different path in Node.js and started developing
[zer](https://github.com/jbmusso/zer) (short for seriali**zer**), a generic
"JavaScript-to-anything" library that uses the ES2015 Proxy object. The lib
builds an AST-ish (I'm learning these :P) which can output to anything,
including Gremlin-Groovy (currently) and most likely Gremlin-bytcode easily (it
could also output to SQL or Cypher, but hey). The trick is to `Proxy()`ify a
`Function` (rather than an `Object`) and intercept calls to that function with
`Proxy.apply()` and mutation of that function properties with `Proxy.get()`
(you can do both since functions are objects in JavaScript).
The `zer` lib allows generating queries such as
`g.V().out().in().bla().method().not().in().tinkerpop().source().code()`
(Grooovy output) but it could easily support things like
`select().from().where()` (and produce SQL-output). Coding the gremlin-bytecode
output should be trivial. It also supports nested traversals and automatic
escaping of bound parameters (it basically escapes all primitives and anything
that is not a `Traversal`). I think it could also support serializing
functions/lambdas since you can do `Function.toString()` in JavaScript and
extract the function body at runtime.
I donât think that the Proxy approach can work in Nashorn since Proxy
canât be emulated in ES5 environment (it only works in Node v6 I recall,
maybe Node v5). However, in Node.js, I think I would just use Proxy objects
that can intercept anything - I think generating code might not be worth it
there. I think this PR is valid in Nashorn but I'm unsure about Node.js.
Note that `zer` and `gremlin-javascript` are distinct libraries. Once
stable enough, `zer` (with just Gremlin-Groovy and Gremlin-Bytecode output)
could be added as a dependency to `gremlin-javascript`.
---
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.
---
[DISCUSS] Traversal Future
Please note the discussion on adding a terminal future method to Traversal on this JIRA ticket: https://issues.apache.org/jira/browse/TINKERPOP-1490 If you have comments, please add them there.
