Support for graph-like queries

[markaddleman]

[TEIID-2481] common table (with) push down improvements - JBoss Issue Tracker reminded me of something I've been meaning to ask for a while:  What are your thoughts on supporting recursive and, more generally, graph queries?  Our own product doesn't have a compelling use case for them yet but we have internal customers making noises regarding graph databases.  Graph queries could always be passed down to the graph database through source native queries but this negates the value of data virtualization.  I guess in a broader sense, I'm curious about your thoughts about making Teiid friendly toward querying the entire VDB as a graph.

One obvious problem is that SQL is pretty hostile to graph-like structures.  As I see it, the problem boils down to having no way to abstract the target of a join.  The problem echoes a conversation we had (and dropped) a long time ago around polymorphic foreign keys.  Talking through the problem as I understand it:  Each graph database node can have an arbitrary schema.  As a data type, SQL would deal with each node as XML.  The graph database can have arbitrary relationships extending from a node while SQL requires that the query specify the target of the relation.  I can maybe see a solution involving a stored procedure that encodes the intelligence about the targets but I bet there are plenty of other snakes in the grass to make a SQL-based approach untenable.  Anyway, this is kind of a long-winded way to realizing that SQL is probably the wrong language and, perhaps, a better approach is to layer a new language/execution-engine onto SQL similar to how OData support was handled.

Like I said at the top, I'm mostly just interested to hear your thoughts on the matter and to get a sense if you see supporting a graph query language in Teiid's future.

[shawkins]

> What are your thoughts on supporting recursive and, more generally, graph queries?

Yes we want to start tackling recursive queries since there are several ansi sql constructs where that is useful.

> I guess in a broader sense, I'm curious about your thoughts about making Teiid friendly toward querying the entire VDB as a graph.

We are mixed on the approach here.  We do have an existing hierarchical model type called an xml document model (use Desinger and import an XSD as a document model).  It provides a way to bind the document structure to a set of sql queries, typically at each child iteration.  From there the xml document model query language (a restricted sql) has a couple of predicates and other tricks to control searching, projection, etc. of the output document - see XML SELECT Command - Teiid 8.8 (draft) - Project Documentation Editor

So the question always is, do we evolve/refine this approach (in tandem with design time support) or should we start afresh with graph/object db virtualization.  Neither seems to gain a lot of traction - and starting afresh has a lot of overlap with the Modeshape project.

> Anyway, this is kind of a long-winded way to realizing that SQL is probably the wrong language and, perhaps, a better approach is to layer a new language/execution-engine onto SQL similar to how OData support was handled.

Yes, both OData and the XML document model logic sit above the normal query engine as they seem best handled outside of the core logic.  At of all the possibilities to broaden object/graph support, I'd expect us to keep the focus on OData as its interest seems high.

[markaddleman]

Thanks for the peek into your thinking.