[
https://issues.apache.org/jira/browse/TINKERPOP-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16236047#comment-16236047
]
Marko A. Rodriguez commented on TINKERPOP-1813:
-----------------------------------------------
The default behavior should use the structure API, not the process API. Why?
1. Efficiency: {{vertex.properties()}} is much more efficient than
{{g.V(vertex).properties()}}. We can not change the approach for a provider at
the expense of the performance of the other providers who use TinkerPop3 as it
should be used (structure+process API).
2. Source leak: What is the {{g}} internal to the step? What are the
strategies? If there is a {{PartitionStrategy}} we would have to deactivate it
to get the data. Which strategies get de-activated? There is no good
algorithmic way of doing this.
If DSEGraph knows the answers to (2), then simply copy/paste the
{{SubgraphStep}} code into {{DseSubgraphStep}} and change the direct calls to
structure API to process API calls. It is really easy to do (see what I did for
the test suite in the PR). If you make a direct copy, your semantics should be
correct. Moreover, {{SubgraphTest}} will verify semantics if you are unsure of
your implementation.
> Subgraph step requires the graph API
> ------------------------------------
>
> Key: TINKERPOP-1813
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1813
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.2.6
> Reporter: Bryn Cooke
> Assignee: Marko A. Rodriguez
> Priority: Minor
>
> SubgraphStrategy uses the graph API to create elements in the subgraph. If a
> graph does not fully support the graph/structure API this it won't work.
> Ideally the graph mutations should use the traversal API.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
