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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/teiid-dev
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev