[jira] [Commented] (TINKERPOP3-724) OLAP Traversal Subgraph Identification

["Matthias Broecheler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP3-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14724025#comment-14724025 ] 

Matthias Broecheler commented on TINKERPOP3-724:
------------------------------------------------

As stated in the ticket, it would be a great first step to be able to elicit all the vertex labels, edge labels and vertex properties that could potentially be accessed. If the entire adjacency list is accessed (e.g. out()) or it cannot be determined, then a special marker like '*' would be returned.

As Marko pointed out, a more sophisticated approach would analyze the traversal lineage and determine edge label constrains with respect to the vertex label.
So, for instance, if you have a traversal like:
g.V.hasLabel('person').out()
it would return that the '*' for edge label is within the context of 'person' vertices - so we only need the adjacency lists of 'person'.

> OLAP Traversal Subgraph Identification
> --------------------------------------
>
>                 Key: TINKERPOP3-724
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-724
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.0.0-incubating
>            Reporter: Matthias Broecheler
>
> Provide the means to pre-compute a superset of all vertex labels, edge labels, and vertex properties that could possibly be accessed during an OLAP graph traversal. This would allow GraphComputer implementations that operate on top of a graph database to limit the amount of data they need to retrieve from the underlying data store to carry out the traversal.
> It is not important that this precomputation is exact, it just needs to provide an upper bound on the needed data to ensure correctness. Any limitation would be helpful to improve performance and TP3 could get increasingly smart about this.
> VertexProgram already has functionality around returning all message scopes which in turn define the edge labels that need to be retrieved. However, for this to be useful a prior one would:
> - Have to extend this functionality to return all message scopes that could ever be invoked by a VP - not just the one at the current iteration
> - Rewrite TraversalVertexProgram to use local message scopes otherwise there is very little to be gained here, see https://issues.apache.org/jira/browse/TINKERPOP3-383



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)