[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code
[ https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15617097#comment-15617097 ] Marko A. Rodriguez commented on TINKERPOP-887: -- A couple of more things: 1. You will need to create serializers for this in Gryo, GraphSON, and in Gremlin-Python. 2. You should make an example of this working. In your PR so we can see its usefulness. Provide a Gremlin Console session showing what the problem is now and how your PR makes this better. Finally, if you want this enabled for all traversals either you do {{g.withStrategies()}} or the user updates the {{TraversalStrategies.GlobalCache}} to have it turned on all the time. Having it on all the time isn't necessary. Regarding "performance impact" -- its more of a problem with "just more stuff" that interacts at the {{TraversalStrategy}} level. We are always trying to get rid of strategies (e.g. {{IdentityRemovalStrategy}} --- its "just a noop too!"). Less less less... not "thanks for adding things" cause guess who gets to maintain your one off idea -- exactly. > FastNoSuchElementException hides stack trace in client code > --- > > Key: TINKERPOP-887 > URL: https://issues.apache.org/jira/browse/TINKERPOP-887 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.0.2-incubating >Reporter: Bryn Cooke >Assignee: Marko A. Rodriguez >Priority: Minor > > I wrote some code that incorrectly assumed that a Gremlin query would return > an element, but it didn't. The surprise was that I got no stack trace and > therefore had no idea where in *my* code I had introduced the error. > I haven't looked in detail at the TP code, so what comes next is speculation: > If FastNoSuchElementException is being used in truly exceptional > circumstances then why is a singleton is used over a normal exception with > stack trace? It could just as easily be converted to a normal exception. > If FastNoSuchElementException is being used for control flow then probably it > shouldn't. Code should check hasNext rather than trying for next and dealing > with an exceptional result. I'm not sure what the current state of things are > in the JVM but at least in the past try catch blocks would inhibit > optimization even without stack traces so this type of code was considered an > antipattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code
[ https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15617075#comment-15617075 ] Marko A. Rodriguez commented on TINKERPOP-887: -- The less logic the better. If you want to debug your traversal, you do {{g.withStrategies(ExceptionHandlingStrategy)}}. Adding strategies is not something to do willy nilly. > FastNoSuchElementException hides stack trace in client code > --- > > Key: TINKERPOP-887 > URL: https://issues.apache.org/jira/browse/TINKERPOP-887 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.0.2-incubating >Reporter: Bryn Cooke >Assignee: Marko A. Rodriguez >Priority: Minor > > I wrote some code that incorrectly assumed that a Gremlin query would return > an element, but it didn't. The surprise was that I got no stack trace and > therefore had no idea where in *my* code I had introduced the error. > I haven't looked in detail at the TP code, so what comes next is speculation: > If FastNoSuchElementException is being used in truly exceptional > circumstances then why is a singleton is used over a normal exception with > stack trace? It could just as easily be converted to a normal exception. > If FastNoSuchElementException is being used for control flow then probably it > shouldn't. Code should check hasNext rather than trying for next and dealing > with an exceptional result. I'm not sure what the current state of things are > in the JVM but at least in the past try catch blocks would inhibit > optimization even without stack traces so this type of code was considered an > antipattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1235) Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest
[ https://issues.apache.org/jira/browse/TINKERPOP-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616791#comment-15616791 ] ASF GitHub Bot commented on TINKERPOP-1235: --- Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/465 > Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest > -- > > Key: TINKERPOP-1235 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1235 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.2.0-incubating >Reporter: Ted Wilmes >Priority: Minor > Labels: breaking, deprecation > > The JUnit Benchmark based performance tests were deprecated for > 3.2.0-incubating given: TINKERPOP-1016 and TINKERPOP-1273 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop pull request #465: TINKERPOP-1235 Removed deprecated "performance"...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/465 --- 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] [Closed] (TINKERPOP-1235) Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest
[ https://issues.apache.org/jira/browse/TINKERPOP-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1235. --- Resolution: Done Assignee: stephen mallette > Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest > -- > > Key: TINKERPOP-1235 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1235 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.2.0-incubating >Reporter: Ted Wilmes >Assignee: stephen mallette >Priority: Minor > Labels: breaking, deprecation > > The JUnit Benchmark based performance tests were deprecated for > 3.2.0-incubating given: TINKERPOP-1016 and TINKERPOP-1273 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-919) Features needs to specify whether 2 vertex properties with same key/value is allowed.
[ https://issues.apache.org/jira/browse/TINKERPOP-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-919. -- Resolution: Done Fix Version/s: 3.2.4 > Features needs to specify whether 2 vertex properties with same key/value is > allowed. > - > > Key: TINKERPOP-919 > URL: https://issues.apache.org/jira/browse/TINKERPOP-919 > Project: TinkerPop > Issue Type: Improvement > Components: structure, test-suite, tinkergraph >Affects Versions: 3.0.2-incubating >Reporter: Marko A. Rodriguez >Assignee: stephen mallette > Fix For: 3.2.4 > > > TinkerGraph does not support two vertex properties with the same key/value. > {code} > gremlin> graph = TinkerGraph.open() > ==>tinkergraph[vertices:0 edges:0] > gremlin> v = graph.addVertex() > ==>v[0] > gremlin> v.property("name","marko") > ==>vp[name->marko] > gremlin> v.property("name","marko") > ==>vp[name->marko] > gremlin> v.properties("name") > ==>vp[name->marko] > {code} > I just noted we don't have this as a {{Feature}} and we should (w/ respective > test cases). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-919) Features needs to specify whether 2 vertex properties with same key/value is allowed.
[ https://issues.apache.org/jira/browse/TINKERPOP-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616788#comment-15616788 ] ASF GitHub Bot commented on TINKERPOP-919: -- Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/463 > Features needs to specify whether 2 vertex properties with same key/value is > allowed. > - > > Key: TINKERPOP-919 > URL: https://issues.apache.org/jira/browse/TINKERPOP-919 > Project: TinkerPop > Issue Type: Improvement > Components: structure, test-suite, tinkergraph >Affects Versions: 3.0.2-incubating >Reporter: Marko A. Rodriguez >Assignee: stephen mallette > Fix For: 3.2.4 > > > TinkerGraph does not support two vertex properties with the same key/value. > {code} > gremlin> graph = TinkerGraph.open() > ==>tinkergraph[vertices:0 edges:0] > gremlin> v = graph.addVertex() > ==>v[0] > gremlin> v.property("name","marko") > ==>vp[name->marko] > gremlin> v.property("name","marko") > ==>vp[name->marko] > gremlin> v.properties("name") > ==>vp[name->marko] > {code} > I just noted we don't have this as a {{Feature}} and we should (w/ respective > test cases). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop pull request #463: TINKERPOP-919 Added supportsDuplicateMultiPrope...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/463 --- 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. ---
Re: Code Reviews - for committers
That's probably fair. Perhaps that's a good rule. At least one person should use CPU to do the docker build and mention that on the PR as part of their VOTE. I also suppose some PRs won't even need the docker run at all. We can just use some common sense with that "rule". On Fri, Oct 28, 2016 at 5:29 PM, Daniel Kuppitz wrote: > Talking about sparing CPU cycles: docker/build.sh -t -i -n takes time, lots > of time. I used to run it regardless of whether somebody else already did > it or not. I won't do that anymore and instead rely on idempotent results > (in the end that's why we originally created the Docker containers). Hence, > if anybody already ran the full build, I will only look through the code > changes and if they look good to me - VOTE: +1. > > Cheers, > Daniel > > > On Fri, Oct 28, 2016 at 9:28 PM, Stephen Mallette > wrote: > > > We're backing up pretty heavily on pull request reviews/votes. > > > > https://github.com/apache/tinkerpop/pulls > > > > Can any committers help us along with some reviews/votes? > > > > Remember - you don't need to have full knowledge of the code to > participate > > in a code review. If the code comes from a core contributor (e.g. marko > > submitting a gremlin-spark bug fix), you mostly need to focus on the big > > picture and generalities of the change and then do a "mvn clean install" > or > > better yet "docker.build.sh -t -i -n". If it all works then "VOTE +1". > > > > Most pull requests for review are super simple, like this one: > > > > https://github.com/apache/tinkerpop/pull/465 (removed deprecated > classes) > > > > All you need to do is check if the classes are gone, if upgrade docs are > > updated and if the thing builds...done. VOTE +1. > > > > Doing reviews is a huge help to the project (even for those who are not > > committers and don't have binding votes, as it is a great way to get > > visibility in the project and learn more about how it works). It would be > > great if folks could make a habit of sparing a few CPU cycles for > TinkerPop > > at the end of a work day or while you sleep so that we can continue to > stay > > agile in our development. > > > > Thanks > > >
[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map but puts non String keys in it!
[ https://issues.apache.org/jira/browse/TINKERPOP-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616705#comment-15616705 ] ASF GitHub Bot commented on TINKERPOP-1483: --- Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/446 I've seen lots of code where people actually use `id` as a property name. ``` gremlin> g = TinkerGraph.open().traversal() ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard] gremlin> g.addV().property("id", UUID.randomUUID()) ==>v[0] gremlin> g.V().valueMap(true) ==>[id:0,id:[02f29cc6-7f04-477c-a884-d5196064109a],label:vertex] gremlin> g.V().project("vertexId","applicationId").by(id).by("id").next() ==>vertexId=0 ==>applicationId=02f29cc6-7f04-477c-a884-d5196064109a ``` Those people would be in big trouble if we would merge this PR: VOTE: -1 > PropertyMapStep returns Map but puts non String keys in it! > - > > Key: TINKERPOP-1483 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1483 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.2.2 >Reporter: JP Moresmau > > PropertyMapStep.map has return type Map, but if includeTokens is > true: > {code} > if (element instanceof VertexProperty) { > map.put(T.id, element.id()); > map.put(T.key, ((VertexProperty) element).key()); > map.put(T.value, ((VertexProperty) element).value()); > } else { > map.put(T.id, element.id()); > map.put(T.label, element.label()); > } > {code} > T.id, T.key and T.value are NOT strings, so code looping through the keys in > Java fails. toString() are missing... But do we rely on having these keys in > other operations? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop issue #446: TINKERPOP-1483: valueMap should always return string k...
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/446 I've seen lots of code where people actually use `id` as a property name. ``` gremlin> g = TinkerGraph.open().traversal() ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard] gremlin> g.addV().property("id", UUID.randomUUID()) ==>v[0] gremlin> g.V().valueMap(true) ==>[id:0,id:[02f29cc6-7f04-477c-a884-d5196064109a],label:vertex] gremlin> g.V().project("vertexId","applicationId").by(id).by("id").next() ==>vertexId=0 ==>applicationId=02f29cc6-7f04-477c-a884-d5196064109a ``` Those people would be in big trouble if we would merge 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. ---
[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code
[ https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616690#comment-15616690 ] Bryn Cooke commented on TINKERPOP-887: -- Is this really going to make a difference to performance? The added step is basically a no-op, so unless there is definitely a performance degradation then it'd be better to avoid the extra complexity for users having to enable a special mode. Perhaps we can evaluate the perf impact before going down this route? If we did have to have a special mode then how would this be activated? Say you have a 100 line gremlin script that you are submitting to gremlin server, you'd want to enable this mode for all traversals in the request. That way when the error occurs you can tell which line it occurred on. Perhaps [~spmallette] has some ideas? Ideally I would like to avoid having to put the entire server in to debug mode. > FastNoSuchElementException hides stack trace in client code > --- > > Key: TINKERPOP-887 > URL: https://issues.apache.org/jira/browse/TINKERPOP-887 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.0.2-incubating >Reporter: Bryn Cooke >Assignee: Marko A. Rodriguez >Priority: Minor > > I wrote some code that incorrectly assumed that a Gremlin query would return > an element, but it didn't. The surprise was that I got no stack trace and > therefore had no idea where in *my* code I had introduced the error. > I haven't looked in detail at the TP code, so what comes next is speculation: > If FastNoSuchElementException is being used in truly exceptional > circumstances then why is a singleton is used over a normal exception with > stack trace? It could just as easily be converted to a normal exception. > If FastNoSuchElementException is being used for control flow then probably it > shouldn't. Code should check hasNext rather than trying for next and dealing > with an exceptional result. I'm not sure what the current state of things are > in the JVM but at least in the past try catch blocks would inhibit > optimization even without stack traces so this type of code was considered an > antipattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-932) Add ability to cancel script execution associated with a Gremlin Server Session
[ https://issues.apache.org/jira/browse/TINKERPOP-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616686#comment-15616686 ] ASF GitHub Bot commented on TINKERPOP-932: -- Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/461 VOTE: +1 > Add ability to cancel script execution associated with a Gremlin Server > Session > > > Key: TINKERPOP-932 > URL: https://issues.apache.org/jira/browse/TINKERPOP-932 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.0.2-incubating >Reporter: Zachary Kurey >Assignee: stephen mallette > Fix For: 3.2.4 > > > Currently with a {{SessionedClient}} there is no way to cancel a long running > script and the client has to depend on Gremlin Server side configured > timeouts before they can execute another script associated with the same > session id. > There is a way we can forcefully close a session from the client side, or > just close the entire Gremlin client. But it would be useful for client side > applications to be able to cancel script execution, have its intermediate > effects rolled back, and be able to continue interacting with the session > without losing session variable state maintained on the Gremlin server side. > Unsure where this should live at an API level, since canceling by session id > isn't relevant for all {{Client}} implementations. If somehow when the > {{CompletableFuture}} returned by {{Client.submitAsync}} could do > this when the {{Future}} is canceled, that would be a nice way to bridge > implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop issue #461: TINKERPOP-932 Added "force" option on session close.
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/461 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 #463: TINKERPOP-919 Added supportsDuplicateMultiProperties()
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/463 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-919) Features needs to specify whether 2 vertex properties with same key/value is allowed.
[ https://issues.apache.org/jira/browse/TINKERPOP-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616661#comment-15616661 ] ASF GitHub Bot commented on TINKERPOP-919: -- Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/463 VOTE: +1 > Features needs to specify whether 2 vertex properties with same key/value is > allowed. > - > > Key: TINKERPOP-919 > URL: https://issues.apache.org/jira/browse/TINKERPOP-919 > Project: TinkerPop > Issue Type: Improvement > Components: structure, test-suite, tinkergraph >Affects Versions: 3.0.2-incubating >Reporter: Marko A. Rodriguez >Assignee: stephen mallette > > TinkerGraph does not support two vertex properties with the same key/value. > {code} > gremlin> graph = TinkerGraph.open() > ==>tinkergraph[vertices:0 edges:0] > gremlin> v = graph.addVertex() > ==>v[0] > gremlin> v.property("name","marko") > ==>vp[name->marko] > gremlin> v.property("name","marko") > ==>vp[name->marko] > gremlin> v.properties("name") > ==>vp[name->marko] > {code} > I just noted we don't have this as a {{Feature}} and we should (w/ respective > test cases). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions
[ https://issues.apache.org/jira/browse/TINKERPOP-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616650#comment-15616650 ] ASF GitHub Bot commented on TINKERPOP-1525: --- Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/462 VOTE: +1 > Plug VertexProgram iteration leak on empty Spark RDD partitions > --- > > Key: TINKERPOP-1525 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1525 > Project: TinkerPop > Issue Type: Bug > Components: hadoop >Affects Versions: 3.2.3 >Reporter: Dan LaRocque > > If SparkExecutor gets an RDD with empty partitions, it can invoke > {{VertexProgram.workerIterationStart}} without ever invoking > {{VertexProgram.workerIterationEnd}}. > For vertex programs that allocate and release meaningful resources in the > start/end methods, this can lead to resource leaks. > I already tested a fix that I made against the 3.2 series. I will submit PRs > momentarily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/462 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. ---
Re: Code Reviews - for committers
Talking about sparing CPU cycles: docker/build.sh -t -i -n takes time, lots of time. I used to run it regardless of whether somebody else already did it or not. I won't do that anymore and instead rely on idempotent results (in the end that's why we originally created the Docker containers). Hence, if anybody already ran the full build, I will only look through the code changes and if they look good to me - VOTE: +1. Cheers, Daniel On Fri, Oct 28, 2016 at 9:28 PM, Stephen Mallette wrote: > We're backing up pretty heavily on pull request reviews/votes. > > https://github.com/apache/tinkerpop/pulls > > Can any committers help us along with some reviews/votes? > > Remember - you don't need to have full knowledge of the code to participate > in a code review. If the code comes from a core contributor (e.g. marko > submitting a gremlin-spark bug fix), you mostly need to focus on the big > picture and generalities of the change and then do a "mvn clean install" or > better yet "docker.build.sh -t -i -n". If it all works then "VOTE +1". > > Most pull requests for review are super simple, like this one: > > https://github.com/apache/tinkerpop/pull/465 (removed deprecated classes) > > All you need to do is check if the classes are gone, if upgrade docs are > updated and if the thing builds...done. VOTE +1. > > Doing reviews is a huge help to the project (even for those who are not > committers and don't have binding votes, as it is a great way to get > visibility in the project and learn more about how it works). It would be > great if folks could make a habit of sparing a few CPU cycles for TinkerPop > at the end of a work day or while you sleep so that we can continue to stay > agile in our development. > > Thanks >
[GitHub] tinkerpop issue #458: Message scope initialization in PeerPressureVertexProg...
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/458 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-1527) Do not override registered strategies in TraversalStrategies.GlobalCache
[ https://issues.apache.org/jira/browse/TINKERPOP-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616592#comment-15616592 ] ASF GitHub Bot commented on TINKERPOP-1527: --- Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/464 VOTE: +1 > Do not override registered strategies in TraversalStrategies.GlobalCache > > > Key: TINKERPOP-1527 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1527 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.3 >Reporter: Marko A. Rodriguez >Assignee: Marko A. Rodriguez > > This may be a non-issue (need to check), but we currently do this in every > {{Graph}} (and {{GraphComputer}}) class. > {code} > static { > TraversalStrategies.GlobalCache.registerStrategies(TinkerGraph.class, > TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance())); > } > {code} > If this static code is loaded every time a {{Graph}} instance is created, > then manually tweaked strategy registrations get overwritten. If this is the > case, then we should do: > {code} > static { > > TraversalStrategies.GlobalCache.registerStrategiesIfNotPresent(TinkerGraph.class,TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance())); > } > {code} > That is, add a {{registerIfNotPresent()}} method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop issue #464: TINKERPOP-1527: Do not override registered strategies ...
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/464 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-1235) Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest
[ https://issues.apache.org/jira/browse/TINKERPOP-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616587#comment-15616587 ] ASF GitHub Bot commented on TINKERPOP-1235: --- Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/465 VOTE: +1 > Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest > -- > > Key: TINKERPOP-1235 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1235 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.2.0-incubating >Reporter: Ted Wilmes >Priority: Minor > Labels: breaking, deprecation > > The JUnit Benchmark based performance tests were deprecated for > 3.2.0-incubating given: TINKERPOP-1016 and TINKERPOP-1273 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop issue #465: TINKERPOP-1235 Removed deprecated "performance" tests.
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/465 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-887) FastNoSuchElementException hides stack trace in client code
[ https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616561#comment-15616561 ] ASF GitHub Bot commented on TINKERPOP-887: -- Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/470 Why is this a default strategy? This should be more of a "turn it on if you are testing." We shouldn't waste clock cycles on every traversal. > FastNoSuchElementException hides stack trace in client code > --- > > Key: TINKERPOP-887 > URL: https://issues.apache.org/jira/browse/TINKERPOP-887 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.0.2-incubating >Reporter: Bryn Cooke >Assignee: Marko A. Rodriguez >Priority: Minor > > I wrote some code that incorrectly assumed that a Gremlin query would return > an element, but it didn't. The surprise was that I got no stack trace and > therefore had no idea where in *my* code I had introduced the error. > I haven't looked in detail at the TP code, so what comes next is speculation: > If FastNoSuchElementException is being used in truly exceptional > circumstances then why is a singleton is used over a normal exception with > stack trace? It could just as easily be converted to a normal exception. > If FastNoSuchElementException is being used for control flow then probably it > shouldn't. Code should check hasNext rather than trying for next and dealing > with an exceptional result. I'm not sure what the current state of things are > in the JVM but at least in the past try catch blocks would inhibit > optimization even without stack traces so this type of code was considered an > antipattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop issue #470: TINKERPOP-887 ExceptionHandlerStrategy
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/470 Why is this a default strategy? This should be more of a "turn it on if you are testing." We shouldn't waste clock cycles on every traversal. --- 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] [Updated] (TINKERPOP-1030) Map common exceptions to HTTP status codes where possible
[ https://issues.apache.org/jira/browse/TINKERPOP-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1030: Assignee: (was: stephen mallette) > Map common exceptions to HTTP status codes where possible > - > > Key: TINKERPOP-1030 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1030 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.1.0-incubating >Reporter: stephen mallette >Priority: Trivial > > If a script throws an exception in the REST API, it would be nice if there > was a way to map that exception to an HTTP status code. The gremlin server > configuration could have a specific set of exception to error code mappings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Code Reviews - for committers
We're backing up pretty heavily on pull request reviews/votes. https://github.com/apache/tinkerpop/pulls Can any committers help us along with some reviews/votes? Remember - you don't need to have full knowledge of the code to participate in a code review. If the code comes from a core contributor (e.g. marko submitting a gremlin-spark bug fix), you mostly need to focus on the big picture and generalities of the change and then do a "mvn clean install" or better yet "docker.build.sh -t -i -n". If it all works then "VOTE +1". Most pull requests for review are super simple, like this one: https://github.com/apache/tinkerpop/pull/465 (removed deprecated classes) All you need to do is check if the classes are gone, if upgrade docs are updated and if the thing builds...done. VOTE +1. Doing reviews is a huge help to the project (even for those who are not committers and don't have binding votes, as it is a great way to get visibility in the project and learn more about how it works). It would be great if folks could make a habit of sparing a few CPU cycles for TinkerPop at the end of a work day or while you sleep so that we can continue to stay agile in our development. Thanks
[jira] [Closed] (TINKERPOP-893) Validate dependency grabs that have TinkerPop dependencies
[ https://issues.apache.org/jira/browse/TINKERPOP-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-893. -- Resolution: Won't Fix Assignee: stephen mallette I was thinking about this one today while doing some testing that involved mucking with dependency exclusions. I sense that implementation of this ticket is just going to end up being fairly superficial. Even eliminating jar conflicts at a TinkerPop level doesn't help prevent problems as there are even conflicts within TinkerPop (i.e. spark-gremlin with gremlin-console - luckily that's never caused problems). Something way more advanced would be required to really prevent these kinds of issues and would likely take us out of scope of what TinkerPop is focused on. Users will just have to take care in their install commands and resolve conflict on their own. > Validate dependency grabs that have TinkerPop dependencies > -- > > Key: TINKERPOP-893 > URL: https://issues.apache.org/jira/browse/TINKERPOP-893 > Project: TinkerPop > Issue Type: Improvement > Components: console, server >Affects Versions: 3.0.2-incubating >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Trivial > > Gremlin Console's {{:install}} command: > https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-console/src/main/groovy/org/apache/tinkerpop/gremlin/console/commands/InstallCommand.groovy > and Gremlin Server's {{bin/gremlin-server.sh -i}} > https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/util/GremlinServerInstall.java > pull down dependencies. A nice check might be to detect dependency conflicts > with TinkerPop libs. For example, if someone tries to use Gremlin 3.1.0 to > {{install}} Titan 1.0.0 (which depends on TinkerPop 3.0.1), we could error > the install and show a nice error to the user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code
[ https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke reopened TINKERPOP-887: -- Please could you take a look at the PR and see if it has any potential? It adds a new strategy that appends a final step to top level traversals that converts any FastNoSuchElementException in to a regular NoSuchElementException. It means that we don't get the stack trace in to the traversal, but clients do get information about where in their code the exception was thrown. > FastNoSuchElementException hides stack trace in client code > --- > > Key: TINKERPOP-887 > URL: https://issues.apache.org/jira/browse/TINKERPOP-887 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.0.2-incubating >Reporter: Bryn Cooke >Assignee: Marko A. Rodriguez >Priority: Minor > > I wrote some code that incorrectly assumed that a Gremlin query would return > an element, but it didn't. The surprise was that I got no stack trace and > therefore had no idea where in *my* code I had introduced the error. > I haven't looked in detail at the TP code, so what comes next is speculation: > If FastNoSuchElementException is being used in truly exceptional > circumstances then why is a singleton is used over a normal exception with > stack trace? It could just as easily be converted to a normal exception. > If FastNoSuchElementException is being used for control flow then probably it > shouldn't. Code should check hasNext rather than trying for next and dealing > with an exceptional result. I'm not sure what the current state of things are > in the JVM but at least in the past try catch blocks would inhibit > optimization even without stack traces so this type of code was considered an > antipattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code
[ https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616254#comment-15616254 ] ASF GitHub Bot commented on TINKERPOP-887: -- GitHub user BrynCooke opened a pull request: https://github.com/apache/tinkerpop/pull/470 TINKERPOP-887 ExceptionHandlerStrategy Added exception handler strategy to convert FastNoSuchElementExceptions in to regular NoSuchElementExceptions when exiting a traversal. You can merge this pull request into a Git repository by running: $ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-887 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/470.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #470 commit 4b80bcd2f12b905a927d61e257c2d4b00f76f609 Author: BrynCooke Date: 2016-10-28T19:04:10Z TINKERPOP-887 Added exception handler strategy to convert FastNoSuchElementExceptions in to regular NoSuchElementExceptions when exiting a traversal. > FastNoSuchElementException hides stack trace in client code > --- > > Key: TINKERPOP-887 > URL: https://issues.apache.org/jira/browse/TINKERPOP-887 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.0.2-incubating >Reporter: Bryn Cooke >Assignee: Marko A. Rodriguez >Priority: Minor > > I wrote some code that incorrectly assumed that a Gremlin query would return > an element, but it didn't. The surprise was that I got no stack trace and > therefore had no idea where in *my* code I had introduced the error. > I haven't looked in detail at the TP code, so what comes next is speculation: > If FastNoSuchElementException is being used in truly exceptional > circumstances then why is a singleton is used over a normal exception with > stack trace? It could just as easily be converted to a normal exception. > If FastNoSuchElementException is being used for control flow then probably it > shouldn't. Code should check hasNext rather than trying for next and dealing > with an exceptional result. I'm not sure what the current state of things are > in the JVM but at least in the past try catch blocks would inhibit > optimization even without stack traces so this type of code was considered an > antipattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop pull request #470: TINKERPOP-887 ExceptionHandlerStrategy
GitHub user BrynCooke opened a pull request: https://github.com/apache/tinkerpop/pull/470 TINKERPOP-887 ExceptionHandlerStrategy Added exception handler strategy to convert FastNoSuchElementExceptions in to regular NoSuchElementExceptions when exiting a traversal. You can merge this pull request into a Git repository by running: $ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-887 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/470.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #470 commit 4b80bcd2f12b905a927d61e257c2d4b00f76f609 Author: BrynCooke Date: 2016-10-28T19:04:10Z TINKERPOP-887 Added exception handler strategy to convert FastNoSuchElementExceptions in to regular NoSuchElementExceptions when exiting a traversal. --- 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-1493) Groovy project doesn't build on Windows
[ https://issues.apache.org/jira/browse/TINKERPOP-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616235#comment-15616235 ] ASF GitHub Bot commented on TINKERPOP-1493: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/456 @pluradj are you going to have votes for these PRs sometime soon? i was sorta waiting for you to be the first to test this out. > Groovy project doesn't build on Windows > --- > > Key: TINKERPOP-1493 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1493 > Project: TinkerPop > Issue Type: Bug > Components: groovy >Affects Versions: 3.2.2 >Reporter: Paul Jackson >Priority: Minor > > Builds on Windows fail for two reasons. First the line to create extTestDir > is creating a path consisting of two full paths concatenated together. The > second drive letter is seen as an illegal character: > {code}private static final File extTestDir = new > File(System.getProperty("user.dir"), > TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code} > Second, when it comes time to delete the directory it is locked. This is > because some instances of JarFile are created on it but not closed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop issue #456: TINKERPOP-1493 Groovy project doesn't build on Windows
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/456 @pluradj are you going to have votes for these PRs sometime soon? i was sorta waiting for you to be the first to test this out. --- 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] Speeding up the build - spark-gremlin
I've done a few runs of our coverage reports this morning with different configurations trying to analyze the effect spark-gremlin has on our test coverage. Why spark-gremlin? Because it takes about 50% of our build time right now and, as such, seemed like a good place to start thinking about how to make improvements to test performance. I didn't not run "integration tests" in any of my analysis, as I'm mostly interested in figuring out how to make "unit tests" faster without losing basic coverage there. Some things I noted: + spark-gremlin unit tests offer good coverage of spark-gremlin itself at about 72% line coverage and 76% branch coverage + the tests on spark-gremlin only add about 3% more branch coverage and 2% more line coverage to gremlin-core. I'm not sure what I expected to find, but that seems pretty small to me. + Removing the groovy or java "process suite" makes almost no difference in coverage - less than 1% + The longest run tests are the spark "io" tests, SparkGraphComputerProcessTest and SparkGraphComputerGroovyProcessTest. Marko, I think you would be best to speak to the implications of this suggestion, but if we make these longer run tests in gremlin-spark into integration tests we cut the speed of the build by roughly 40%. If we do that we sacrifice the minimal coverage we get in gremlin-core and our overall coverage of spark-gremlin drops by only 3% on lines of code and about 7% on branch coverage, so there is not a lot of loss there. If a change goes into gremlin-core, then it would be smart to run: "mvn clean install && mvn verify -pl gremlin-spark -DskipIntegrationTests=false". we would look to catch that in pull requests during code review. If we go with this approach, I could do some further analysis on spark-gremlin and determine if some new tests could be added to gain back the lost coverage via unit tests (that I presume will require mocking) so that we can get those few percentage points back (and maybe more). Anyway, I'll assume lazy consensus on this in 72 hours (Monday, October 31, 2016, 2:30pm) and move forward if there are no objections.
[jira] [Commented] (TINKERPOP-1534) Gremlin Server instances leaking in tests
[ https://issues.apache.org/jira/browse/TINKERPOP-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15615813#comment-15615813 ] ASF GitHub Bot commented on TINKERPOP-1534: --- GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/469 TINKERPOP-1534 Improve GraphProvider ability to release resources https://issues.apache.org/jira/browse/TINKERPOP-1534 Specifically, made `AbstractGremlinSuite` attempt to `close()` a `GraphProvider` if it implemented `AutoCloseable`. Added better logging to `gremlin-python` server start/stop script. Removed `DriverRemoteConnectionTest` as it was an ignored test anyway and a remnant of the original way we tested `gremlin-python`. Implemented `AutoCloseable` on `RemoteGraphProvider` to kill Gremlin Server which is no longer started statically. Interestingly the issue might have had less to do with "proper shutdown" and more with: https://github.com/apache/tinkerpop/commit/30c2600bff074a7053cecab90baeccb60b087456 which was fixed on `tp31` and merged forward. Anyway, there should be no more leaking of Gremlin Server log messages into hadoop/spark/etc (i.e. anything after the gremlin server portion of the build). Works with `mvn clean install`. VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1534 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/469.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #469 commit 9a8c2d20ea24ed71b7b1350b9a31f27fccfb0527 Author: Stephen Mallette Date: 2016-10-28T15:55:47Z TINKERPOP-1534 Improve GraphProvider ability to release resources Specifically, made AbstractGremlinSuite attept to close() a GraphProvider if it implemented AutoCloseable. Added better logging to gremlin-python server start/stop script. Removed DriverRemoteConnectionTest as it was an ignored test anyway and a remnant of the original way we tested gremlin-python. Implemented AutoCloseable on RemoteGraphProvider to kill Gremlin Server which is no longer started statically. > Gremlin Server instances leaking in tests > - > > Key: TINKERPOP-1534 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1534 > Project: TinkerPop > Issue Type: Bug > Components: server, test-suite >Affects Versions: 3.2.3 >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.2.4 > > > Even though Gremlin Server appears to be shut down, it still produces output > in tests from spark/hadoop/etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop pull request #469: TINKERPOP-1534 Improve GraphProvider ability to...
GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/469 TINKERPOP-1534 Improve GraphProvider ability to release resources https://issues.apache.org/jira/browse/TINKERPOP-1534 Specifically, made `AbstractGremlinSuite` attempt to `close()` a `GraphProvider` if it implemented `AutoCloseable`. Added better logging to `gremlin-python` server start/stop script. Removed `DriverRemoteConnectionTest` as it was an ignored test anyway and a remnant of the original way we tested `gremlin-python`. Implemented `AutoCloseable` on `RemoteGraphProvider` to kill Gremlin Server which is no longer started statically. Interestingly the issue might have had less to do with "proper shutdown" and more with: https://github.com/apache/tinkerpop/commit/30c2600bff074a7053cecab90baeccb60b087456 which was fixed on `tp31` and merged forward. Anyway, there should be no more leaking of Gremlin Server log messages into hadoop/spark/etc (i.e. anything after the gremlin server portion of the build). Works with `mvn clean install`. VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1534 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/469.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #469 commit 9a8c2d20ea24ed71b7b1350b9a31f27fccfb0527 Author: Stephen Mallette Date: 2016-10-28T15:55:47Z TINKERPOP-1534 Improve GraphProvider ability to release resources Specifically, made AbstractGremlinSuite attept to close() a GraphProvider if it implemented AutoCloseable. Added better logging to gremlin-python server start/stop script. Removed DriverRemoteConnectionTest as it was an ignored test anyway and a remnant of the original way we tested gremlin-python. Implemented AutoCloseable on RemoteGraphProvider to kill Gremlin Server which is no longer started statically. --- 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-1474) API Alignment Between Java Gremlin Graph Structure and GLVs
[ https://issues.apache.org/jira/browse/TINKERPOP-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15615735#comment-15615735 ] stephen mallette commented on TINKERPOP-1474: - I'm coming around to the side where I think we should include the properties. As I mentioned in my comment below, it doesn't seem like a lot of code to add. We would draw the line at reading the properties. I will start a thread on the dev list (and link it here) to make sure the community is on-board with this direction. [~okram] may still not like the idea though. > API Alignment Between Java Gremlin Graph Structure and GLVs > --- > > Key: TINKERPOP-1474 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1474 > Project: TinkerPop > Issue Type: Bug > Components: io >Affects Versions: 3.2.2 >Reporter: Adam Holmberg > > The current Java GraphSON implementation and that in the Python GLV leave > some question about what *should* be returned from a simple traversal like > `g.V()`. > The java implementation presently assumes that properties could be present > and returns a DetachedVertex: > https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433 > The python implementation assumes no such thing and returns something more > reminiscent of a ReferenceVertex: > https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242 > Is the java version overreaching, and should not expect properties unless a > step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or > should the Python version be expanded? > Is there something we can do to establish guidelines for this, and align > these APIs? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[DISCUSS] Properties in GLVs
Note that there is an issue in JIRA that discusses whether or not we should include properties on Vertex/Edge/VertexProperty structure classes in the GLVs. I've personally wobbled back and forth on it for a while, but I think we should just add them with the intent to support read operations from Gremlin Server. Ultimately, it will be the user's decision to return properties with their Vertex/Edge/VertexProperty instances given the "mime type" they choose for the serialization process. So users who want them get them and those that don't (like the guy with a million multiproperties on a Vertex) can ignore them. Anyway, please comment on the JIRA issue if you have thoughts on the matter: https://issues.apache.org/jira/browse/TINKERPOP-1474
[jira] [Created] (TINKERPOP-1534) Gremlin Server instances leaking in tests
stephen mallette created TINKERPOP-1534: --- Summary: Gremlin Server instances leaking in tests Key: TINKERPOP-1534 URL: https://issues.apache.org/jira/browse/TINKERPOP-1534 Project: TinkerPop Issue Type: Bug Components: server, test-suite Affects Versions: 3.2.3 Reporter: stephen mallette Assignee: stephen mallette Fix For: 3.2.4 Even though Gremlin Server appears to be shut down, it still produces output in tests from spark/hadoop/etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs
[ https://issues.apache.org/jira/browse/TINKERPOP-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15615674#comment-15615674 ] Andy Tolbert commented on TINKERPOP-1474: - Just to follow up on this to make sure it doesn't slide off the radar, can I get some clarification on this? {quote} is deserializing gremlin bytecode into objects (vertex, edge, vertexproperty, etc.) outside the scope of gremlin-python? {quote} Mostly just looking for clarification for future GLV implementations. > API Alignment Between Java Gremlin Graph Structure and GLVs > --- > > Key: TINKERPOP-1474 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1474 > Project: TinkerPop > Issue Type: Bug > Components: io >Affects Versions: 3.2.2 >Reporter: Adam Holmberg > > The current Java GraphSON implementation and that in the Python GLV leave > some question about what *should* be returned from a simple traversal like > `g.V()`. > The java implementation presently assumes that properties could be present > and returns a DetachedVertex: > https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433 > The python implementation assumes no such thing and returns something more > reminiscent of a ReferenceVertex: > https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242 > Is the java version overreaching, and should not expect properties unless a > step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or > should the Python version be expanded? > Is there something we can do to establish guidelines for this, and align > these APIs? -- This message was sent by Atlassian JIRA (v6.3.4#6332)