[
https://issues.apache.org/jira/browse/TINKERPOP3-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14986815#comment-14986815
]
Jonathan Ellithorpe commented on TINKERPOP3-936:
------------------------------------------------
I see, so for each test the supported graph features could potentially be
different. Further, in the worst case, it may be necessary to first connect to
the remote database before being able to fully determine the supported
features. Ay dios mio!
In the worst case scenario, then, there's really nothing that can be done. A
connection must be established to the remote database before the features can
be determined, for each and every test. For other implementations the features
are determined locally given the configuration, and still for others, the
features are hard-set and independent of the configuration.
I can see a couple of solutions, but they both have fatal flaws. The first
would be to create a static method in the API that returns the graph features
given a configuration parameter. The implementation of this method does the
minimum amount necessary to determine the graph features, making remote
connections in the worst case. This, unfortunately, doubles the work now in the
worst case, making remote connections to get the features, and then again to
actually execute the test. The second solution I can think of would be to have
a separate method for construction of the graph object (given a config) and for
opening the graph (typically for making remote connections or opening files on
disk). The graph object is constructed before querying its features, and opened
before executing the test. This would allow the API implementer the freedom to
choose what goes in which stage in order to minimally satisfy the features
query. Frankly, though, this seems too much and too confusing to the
implementer just to get around this problem of the unit tests taking too long...
> Check feature requirements before opening graph during tests
> ------------------------------------------------------------
>
> Key: TINKERPOP3-936
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-936
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: test-suite
> Affects Versions: 3.0.2-incubating
> Reporter: Jonathan Ellithorpe
> Assignee: stephen mallette
> Priority: Minor
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> In AbstractGremlinTest, setup() opens a graph before checking whether or not
> the graph meets the feature requirements to run the current test. In the case
> that the graph does not meet the requirements, then opening the graph was
> wasted work, since the test will not run. For some graph database
> implementations this wasted work may be trivial, but for others it may be
> significant (for example, if the graph object must establish connections to
> remote servers). This wasted work adds up for each test that is skipped.
> If there is a way to check the features of a given graph implementation
> without instantiating a new graph instance, then the order of graph
> instantiation and feature requirement checking could be reversed, and
> significantly reduce the time it takes to run a suite of unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
