[teiid-dev] XML as a source

[John Doyle]

That SQL doesn't make any sense you say.  Right you are.  :)  But it does get to my point.

How do we create SQL for this:

Get all PO.Numbers where any of the items has a quantity greater than 10.

~jd

----- "John Doyle" <jdoyle at redhat.com> wrote:

> I'm not really arguing against XPath as the syntax to express the
> mapping, it's a good solution.  I'm describing a higher level problem
> that I don't see the solution for.  
> 
> Lets say we have a virtual view we have created for a purchase order
> document and we have defined three tables with the proposed new
> functions: PO, Address, and Item.  POs have both BillTo and ShipTo
> Addresses as well as a list of Items.  Now we query this view with the
> following:
> 
> Select PO.Number from PO, Item where Item.Quantity > 10;
> 
> If our virtual tables defined by our functions are just returning row
> sets, how does this join get resolved?  How does the engine know?  In
> the XML-Relational implementation we create keyed relations in the
> model and then insert keys into the document as it is parsed so that
> we engine can resolve the join across the result sets we produce.
> 
> ~jd
> 
> ----- "Ramesh Reddy" <rareddy at redhat.com> wrote:
> 
> > I see that in the current source model's table and column property
> > "NameInSource" already contains a xpath expression to get to column
> > information from a given XML document. How is proposed function
> based
> > model is different, than just making a what is source model now to
> a
> > virtual model in future. However, this forces the XML --> Table
> > mappings
> > will be done at the engine level, thus pushes relational issues to
> > engine. Am I interpreting the scenario correctly?
> > 
> > On Thu, 2009-09-17 at 12:05 -0400, John Doyle wrote:
> > > I wanted to pick up the discussion started in TEIID_817 around
> > improvements/alternatives to the current implementation of the XML
> > Connectors (https://jira.jboss.org/jira/browse/TEIID-817). 
> > Specifically I want to get a better understanding of the idea Steve
> > presented.
> > > ___
> > > ...
> > > The alternative we've talked about before is to treat the source
> > access and table extraction as primary and separate functions of
> > Teiid. Executing a web service could have a procedure like xml
> > getDoc(xml param) - which is essentially the approach of the XML
> > Source logic. On top of that there can be helper SQL/XML like
> > functions to map a rowset to xml, such as xmlforest, and the result
> > xml to "tables" - something like extract(xml param, xpath as col1,
> > xpath as col2....). At the very least adding a rowset or table
> type.
> > > __
> > > 
> > > 
> > > How do you envision exposing the functions, specifically
> functions
> > that turn XML into a rowset or table, to users?  Would they be
> > available in Transformations that define virtual tables?  This
> would
> > retain the central value of the XML-Relational connectors, and
> remove
> > much of the complexity of how it does it.
> > > 
> > > One of the challenges in this is that we need to be able to
> extract
> > multiple virtual tables from a single XML document, and retain
> > (create) the relationships between them.  For instance, if we
> extract
> > PO, Address and Item tables from a Purchase Order xml document, we
> > need to be able to map the item to the purchase order that it came
> > from.  We do this currently by adding id's to the xml document and
> > exposing them in the model we generate.
> > > 
> > > One thing I'll note is that passing around XML has it's limits. 
> > Some of our customers are handling very large XML.
> > > 
> > > ~jd
> > 
> > _______________________________________________
> > teiid-dev mailing list
> > teiid-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-dev
> _______________________________________________
> teiid-dev mailing list
> teiid-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev