[jira] [Commented] (TINKERPOP-1979) Several OLAP issues in MathStep
[
https://issues.apache.org/jira/browse/TINKERPOP-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16506569#comment-16506569
]
ASF GitHub Bot commented on TINKERPOP-1979:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/874
VOTE: +1
> Several OLAP issues in MathStep
> ---
>
> Key: TINKERPOP-1979
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1979
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Reporter: Daniel Kuppitz
>Priority: Major
>
> {{MathStep}} has a few issues when used in an OLAP query and I think the
> worst thing is that both of them are silently ignored by our test suite.
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin> g.V().outE().math("0-_").by("weight")
> It is not possible to access more than a path element's id on GraphComputer:
> MathStep(0-_,[value(weight)]) requires PROPERTIES
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}
> This one is just wrong and I'm not sure why {{ComputerVerificationStrategy}}
> assumes that the step is trying to leave the star graph. The next one works
> for {{TinkerGraphComputer}} but fails in Spark with a serialization-related
> exception:
> {noformat}
> g.V().values("age").math("_")
> // leads to the following (ignored) exception:
> java.lang.IllegalStateException: org.apache.spark.SparkException: Task not
> serializable
> at
> org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.VertexProgramStep.processNextStart(VertexProgramStep.java:88)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:50)
> at
> org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.ComputerResultStep.processNextStart(ComputerResultStep.java:68)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:200)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.forEachRemaining(Traversal.java:265)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MathTest.serializationTest(MathTest.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:53)
> at
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:37)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:213)
> at
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:51)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:2
[GitHub] tinkerpop issue #874: TINKERPOP-1979 Fix math() on OLAP/Spark
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/874 VOTE: +1 ---
Repeated Travis .Failures on .NET
A lot of PRs failing build because of .NET. The error I consistently see is: 127.43s$ curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg curl: (7) Failed to connect to packages.microsoft.com port 443: Connection timed out gpg: no valid OpenPGP data found. The command "curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg" failed and exited with 2 during . Anyone have an ideas as to what's going on there?
[jira] [Commented] (TINKERPOP-1518) Provide a way for providers to expose static Graph.Features to tests
[
https://issues.apache.org/jira/browse/TINKERPOP-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16506556#comment-16506556
]
ASF GitHub Bot commented on TINKERPOP-1518:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/873
Good point - updated to "Provide a way for providers to expose static
Graph.Features to tests"
> Provide a way for providers to expose static Graph.Features to tests
>
>
> Key: TINKERPOP-1518
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1518
> Project: TinkerPop
> Issue Type: Improvement
> Components: test-suite
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0
>
>
> Determine if there's a way to cache graph features to avoid having to load a
> {{Graph}} instance for a test. That could save some test cycles for graphs
> that dont' support a test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-1518) Provide a way for providers to expose static Graph.Features to tests
[
https://issues.apache.org/jira/browse/TINKERPOP-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1518:
Summary: Provide a way for providers to expose static Graph.Features to
tests (was: Cache Graph.Features)
> Provide a way for providers to expose static Graph.Features to tests
>
>
> Key: TINKERPOP-1518
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1518
> Project: TinkerPop
> Issue Type: Improvement
> Components: test-suite
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0
>
>
> Determine if there's a way to cache graph features to avoid having to load a
> {{Graph}} instance for a test. That could save some test cycles for graphs
> that dont' support a test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #873: TINKERPOP-1518 Cache Graph.Features for tests
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/873 Good point - updated to "Provide a way for providers to expose static Graph.Features to tests" ---
[jira] [Commented] (TINKERPOP-1979) Several OLAP issues in MathStep
[
https://issues.apache.org/jira/browse/TINKERPOP-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16506554#comment-16506554
]
ASF GitHub Bot commented on TINKERPOP-1979:
---
GitHub user spmallette opened a pull request:
https://github.com/apache/tinkerpop/pull/874
TINKERPOP-1979 Fix math() on OLAP/Spark
https://issues.apache.org/jira/browse/TINKERPOP-1979
Should be working now - just a serialization problem and fix to dealing
with requirements for `PathProcessor` on `MathStep`. Note that you still can't
access path labels with `math()` in OLAP after this fix or you will run afoul
of standard behavior of `ComputerVerificationStrategy`. I think that's just a
limitation of the overall design with OLAP and path.
All tests pass with `docker/build.sh -t -n -i`
VOTE +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1979
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/874.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 #874
commit 9f8f3b61b8e69624b2ac7aac3c98dcace55a079f
Author: Stephen Mallette
Date: 2018-06-08T16:50:00Z
TINKERPOP-1979 Fixed OLAP bug with math() step
math() can now execute in OLAP with by() modulators if the expression given
to math() does not access path labels.
commit a6e0a2d55c6b5bb9a710a53b8dfc208696416fe2
Author: Stephen Mallette
Date: 2018-06-08T20:53:30Z
TINKERPOP-1979 Get math() working on spark properly
The Expression class was not serializable and Spark was not happy. Wrapped
it up in another class that was and now tests work on spark ok.
> Several OLAP issues in MathStep
> ---
>
> Key: TINKERPOP-1979
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1979
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Reporter: Daniel Kuppitz
>Priority: Major
>
> {{MathStep}} has a few issues when used in an OLAP query and I think the
> worst thing is that both of them are silently ignored by our test suite.
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin> g.V().outE().math("0-_").by("weight")
> It is not possible to access more than a path element's id on GraphComputer:
> MathStep(0-_,[value(weight)]) requires PROPERTIES
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}
> This one is just wrong and I'm not sure why {{ComputerVerificationStrategy}}
> assumes that the step is trying to leave the star graph. The next one works
> for {{TinkerGraphComputer}} but fails in Spark with a serialization-related
> exception:
> {noformat}
> g.V().values("age").math("_")
> // leads to the following (ignored) exception:
> java.lang.IllegalStateException: org.apache.spark.SparkException: Task not
> serializable
> at
> org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.VertexProgramStep.processNextStart(VertexProgramStep.java:88)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:50)
> at
> org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.ComputerResultStep.processNextStart(ComputerResultStep.java:68)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:200)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.forEachRemaining(Traversal.java:265)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MathTest.serializationTest(MathTest.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> or
[GitHub] tinkerpop pull request #874: TINKERPOP-1979 Fix math() on OLAP/Spark
GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/874 TINKERPOP-1979 Fix math() on OLAP/Spark https://issues.apache.org/jira/browse/TINKERPOP-1979 Should be working now - just a serialization problem and fix to dealing with requirements for `PathProcessor` on `MathStep`. Note that you still can't access path labels with `math()` in OLAP after this fix or you will run afoul of standard behavior of `ComputerVerificationStrategy`. I think that's just a limitation of the overall design with OLAP and path. All tests pass with `docker/build.sh -t -n -i` VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1979 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/874.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 #874 commit 9f8f3b61b8e69624b2ac7aac3c98dcace55a079f Author: Stephen Mallette Date: 2018-06-08T16:50:00Z TINKERPOP-1979 Fixed OLAP bug with math() step math() can now execute in OLAP with by() modulators if the expression given to math() does not access path labels. commit a6e0a2d55c6b5bb9a710a53b8dfc208696416fe2 Author: Stephen Mallette Date: 2018-06-08T20:53:30Z TINKERPOP-1979 Get math() working on spark properly The Expression class was not serializable and Spark was not happy. Wrapped it up in another class that was and now tests work on spark ok. ---
[jira] [Commented] (TINKERPOP-1518) Cache Graph.Features
[
https://issues.apache.org/jira/browse/TINKERPOP-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16506524#comment-16506524
]
ASF GitHub Bot commented on TINKERPOP-1518:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/873
VOTE: +1
Though I would change the Jira ticket title before it makes it into the
CHANGELOG, as the implementation doesn't really cache anything.
> Cache Graph.Features
>
>
> Key: TINKERPOP-1518
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1518
> Project: TinkerPop
> Issue Type: Improvement
> Components: test-suite
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0
>
>
> Determine if there's a way to cache graph features to avoid having to load a
> {{Graph}} instance for a test. That could save some test cycles for graphs
> that dont' support a test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #873: TINKERPOP-1518 Cache Graph.Features for tests
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/873 VOTE: +1 Though I would change the Jira ticket title before it makes it into the CHANGELOG, as the implementation doesn't really cache anything. ---
[jira] [Commented] (TINKERPOP-1831) Refactor EventStrategy
[
https://issues.apache.org/jira/browse/TINKERPOP-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16506505#comment-16506505
]
ASF GitHub Bot commented on TINKERPOP-1831:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/872
VOTE: +1
> Refactor EventStrategy
> ---
>
> Key: TINKERPOP-1831
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1831
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Labels: breaking
> Fix For: 3.4.0
>
>
> {{EventStrategy}} has a few issues that could be smoothed out, but not
> without an allowance for breaking change in the API:
> * For the creation of new properties, an empty detached property is created
> to represent it - now that detachment is configurable, that doesn't always
> make sense. For example, if you configured for reference detachment then you
> would probably want a {{ReferenceProperty}} instead. Not sure how this should
> be resolved, but it probably needs a change to the eventing API itself
> * Detachment is configured a bit strangely with the use of {{null}} and
> passing classes for the appropriate detachment factorieswould be nicer to
> have an interface to represent this stuff.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #872: TINKERPOP-1831 Refactored EventStrategy
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/872 VOTE: +1 ---
[DISCUSS] Getting "Practical Gremlin" more visibilty
I'm not sure what we should do about this, but Kelvin's book, Practical Gremlin, is really the best thing out there for learning Gremlin. I mean, we have lots of good documentation in TinkerPop for sure, but it is written as more of a reference than a cohesive resource that you can go to for your paced learning. So while we have more than enough documentation for users to be able to figure out how to use our stuff, it's not quite the same learning experience that Practical Gremlin is. There's lots of good reason that it is the way it is. I think it's hard to keep a cohesive style when lots of different authors contribute to the same set of documents. We have also built our documentation in a very piecemeal style as the software has evolved and it sorta reads that way. We did do some smart things with "tutorials", but we don't have enough of them tying together disparate parts of the documentation.Anywaylucky for us, Practical Gremlin is doing a great job of filling this gap. What bothers me however, is that there are still developers who haven't heard of the book! The message still isn't getting out there. The obvious suggestion, which may have been made before, is that we place a link to the book right on the TinkerPop home page. I think that would be a start, but I think that perhaps even more visibility might be necessary. Maybe Practical Gremlin needs a good logo? Thoughts on what a logo should look like? Maybe we put the logo up there on the home page in place of where the "getting started" tutorial is? Other ideas? So the answer to all that might be "yes", "yes" and more "yes", but it is important that we also consider that Practical Gremlin is a third-party resource and that we would be linking away from the project documentation in a reasonably public way. As an Apache project, it is my understanding that our site should be the primary source for users to get their information on how to use the software. I mostly just want to acknowledge that point because as I mentioned earlier, I think TinkerPop has more than sufficient reference documentation. It's not as though we link our documentation to Practical Gremlin to give readers the source of information. It in fact works the other way around - Practical Gremlin treats our documentation as the reference (perhaps we could get a few more links back to us in there too - hehe). I think that as long as that is true, we satisfy our community requirements on documentation. Not sure if anyone would argue against that So, with all that said, any thoughts on what I propose above?
[jira] [Commented] (TINKERPOP-1942) Binary serialization format
[ https://issues.apache.org/jira/browse/TINKERPOP-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16506291#comment-16506291 ] Kevin Gallardo commented on TINKERPOP-1942: --- Hi all, will throw this out there: TIL about a binary format developed by the team from Jackson: [https://github.com/FasterXML/smile-format-specification] supposedly this format has the same characteristics as JSON in terms of composability, so maybe something that could be for use here. If this fits the use case it would allow to having to re-create a new format from scratch, it would also mean that this comes with already some libraries supposedly optimized for example in Java and others like the current Jackson libraries are. Disclaimer: Unfortunately I haven't had a chance to follow the full conversation here yet but wanted to mention that if anybody wants to have a look. > Binary serialization format > --- > > Key: TINKERPOP-1942 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1942 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Priority: Major > > We should provide a binary serialization format designed to reduce > serialization overhead and minimizing the size of the payload that is > transmitted over the wire. > It could be implemented in a very similar way as Kryo support but with > interoperability in mind and ultimately we could fade Gryo out, as now with > the GLVs it doesn't have a role to play. > The main benefit would be the performance improvement, making serialization > and deserialization processing time negligible on both the server and the > client. > Background: > https://lists.apache.org/thread.html/13e70235591853801bab16ed457ee4f56f3dfe2d1c5817c34a036408@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1518) Cache Graph.Features
[
https://issues.apache.org/jira/browse/TINKERPOP-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16505942#comment-16505942
]
ASF GitHub Bot commented on TINKERPOP-1518:
---
GitHub user spmallette opened a pull request:
https://github.com/apache/tinkerpop/pull/873
TINKERPOP-1518 Cache Graph.Features for tests
https://issues.apache.org/jira/browse/TINKERPOP-1518
For graphs that have an expensive startup time but a static set of
`Graph.Features` the new `GraphProvider.getStaticFeatures()` method should help
speed their test times as it will prevent creation of a new `Graph` instance
for the test if the graph does not support the requisite features. For testing
purposes, this capability was implemented for Neo4j, but it didn't do much to
speed the execution time of the test suite - saved a couple minutes or so. It's
generally pretty cheap to create Neo4j instances themselves, so I guess that is
expected.
(just issued the PR, not quite ready for VOTE yet)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1518
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/873.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 #873
commit aec170982aa03d1a07248721cb045ba95e11188b
Author: Stephen Mallette
Date: 2018-06-08T00:15:53Z
TINKERPOP-1518 GraphProvider allows for caching of graph features
commit 221fda584c6baf7c65eb4e6eebf72bb0ba251de4
Author: Stephen Mallette
Date: 2018-06-08T11:45:29Z
TINKERPOP-1518 Minor refactoring - extracted requirement check function
> Cache Graph.Features
>
>
> Key: TINKERPOP-1518
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1518
> Project: TinkerPop
> Issue Type: Improvement
> Components: test-suite
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0
>
>
> Determine if there's a way to cache graph features to avoid having to load a
> {{Graph}} instance for a test. That could save some test cycles for graphs
> that dont' support a test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #873: TINKERPOP-1518 Cache Graph.Features for tests
GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/873 TINKERPOP-1518 Cache Graph.Features for tests https://issues.apache.org/jira/browse/TINKERPOP-1518 For graphs that have an expensive startup time but a static set of `Graph.Features` the new `GraphProvider.getStaticFeatures()` method should help speed their test times as it will prevent creation of a new `Graph` instance for the test if the graph does not support the requisite features. For testing purposes, this capability was implemented for Neo4j, but it didn't do much to speed the execution time of the test suite - saved a couple minutes or so. It's generally pretty cheap to create Neo4j instances themselves, so I guess that is expected. (just issued the PR, not quite ready for VOTE yet) You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1518 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/873.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 #873 commit aec170982aa03d1a07248721cb045ba95e11188b Author: Stephen Mallette Date: 2018-06-08T00:15:53Z TINKERPOP-1518 GraphProvider allows for caching of graph features commit 221fda584c6baf7c65eb4e6eebf72bb0ba251de4 Author: Stephen Mallette Date: 2018-06-08T11:45:29Z TINKERPOP-1518 Minor refactoring - extracted requirement check function ---
