1. Field of the Invention
This invention relates to the evaluation of XQuery ‘FLOWR’ Expressions using XML Indexing Technologies. In particular, this invention describes use of XML Indexing Mechanisms used during XML Pivot Join (as known as XANDOR for XML Anding and ORing) to support the evaluation of XQuery ‘FLWOR’ Expressions over a collection of XML documents, supporting Multiple Extractions and Binding Order.
2. Description of the Related Art
XPath and XQuery are two common languages used to query XML documents. XPath is a path expression language for selecting and extracting data within XML documents. An XPath expression is comprised of steps where each step specifies an axis, specifying the direction of evaluation from the current context node (i.e. child or descendant, etc.), and a node test specifying the kind and name of nodes within the current XML document to select and/or extract from, and predicates that limit the selection of these nodes.
XQuery is a language for querying, iterating (i.e. FOR), aggregating (i.e. LET), transforming, and constructing XML data. XQuery uses XPath to address specific parts of XML documents and is semantically similar to structured query language (SQL). A typical SQL-like XQuery syntax uses “For, Let, Where, Order by, and Return” clauses in a “FLWOR” expression.
The XML pivot join procedure takes a collection of XML documents and returns only those documents that satisfy some XPath Expression. The XML pivot join procedure uses XML index scans to filter XML index entries that match legs of a XPath expression. For example, the XPath expression, “/a/b[(c=5) AND (d=6)],” selects ‘b’ element nodes within XML documents whose parent element node is ‘a’, and whose immediate child node c=5 and child node d=6. The resulting output ‘b’ element nodes will be from qualifying XML documents that satisfy the conditions of the XPath expression.
Several intermediate structures may be created to fulfill an XML pivot join request. A query tree may be generated, from the query, which describes the query in tree representation. A paths table may be created, from the collection of XML documents, to describe every unique path within each document, including paths that are non-relevant to the query. Next, entries from the paths table may be matched against the query tree and qualifying paths may be combined to form a paths tree. Finally, a match graph is constructed by finding paths in the paths tree that match steps in the query tree.
In the present art, XML Pivot Join implementations can provide either inter-document level filtering or return single extractions (e.g. a single set of results) based on an XPath query. However, current XML Pivot Join implementations fail to permit multiple extractions and provide improper results due to failure to respect binding order for an XQuery FLWOR expression. Throughout this specification the terminology ‘extraction’ means a document or a portion of a document retrieved from a single document or group of documents, where this retrieval is based on the document or document portion matching specified criteria.
Applicants assert that a need exists for a method and apparatus that properly handles a evaluation of XQuery FLWOR (for-let-where-return) expressions that require returning of Multiple Extractions from a preselected XML document, as well as the support for binding order thereby extending an XML pivot join procedure by providing both inter-document level filtering as well as intra-document level filtering.
The present invention has been developed in response to the present state of the art, and in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available XQuery FLWOR expression handling techniques. Accordingly, the present invention has been developed to provide an apparatus, system, and method for handling multiple extractions, properly handling of FOR and LET bindings, as well as the support for binding order compliance during an XML pivot join procedure.
Given an XQuery FLWOR expression, XML indexes are used to identify locations within XML documents that satisfy the query as a whole, taking into account structural constraints specified in XPath expression fragments within the FLWOR expression, and handling the semantics specified by FOR and LET bindings, and supporting binding order specified by the FOR bindings. Note that binding order may be specified by an optimizer rather than the original query, because the optimizer may determine an order for the bindings that optimizes query evaluation performance.
Preferably, inter-document level filtering is accomplished first to reach a candidate XML document that matches the XQuery FLWOR expression, then Intra-document level filtering is accomplished by finding sub-trees within the document that match the XQuery FLWOR expression.
Conventional techniques lack an XML indexing algorithm that supports XQuery FLWOR expressions in the manner of the present invention. Those skilled in the art will appreciate that the present invention replaces the combined functionality of an XML Indexing component that filters XML documents in a collection and a XML Evaluation engine that actually processes the an XML document given a XQuery expression.
In one embodiment, a computer system includes program code adapted to filter a collection of XML documents for documents that satisfy an XQuery FLWOR expression and extract document nodes referred to by the XPath expressions in the XQuery FLWOR expression while honoring binding order specified in the XQuery FLWOR expression.
The program code first provides an XML index of node paths for a collection of XML documents and an XQuery FLWOR expression having a plurality of “FOR or LET” bindings where the plurality of “FOR or LET” bindings further comprise one or more “FOR” and one or more “LET” bindings. The program code next generates a path tree and a match graph according to the XQuery FLWOR expression and based on a set of linear XPaths identified in the XQuery FLWOR expression as well as a set of node paths in the collection of XML documents that match the steps of the linear XPaths. Next, the program code positions and advances a plurality of index cursors, where each index cursor points to a match for a linear XPath step, each match is represented by a match node in the match graph, and each match refers to a document node location in the collection of XML documents. The plurality of index cursors includes an inner cursor and an outer cursor and each of the cursors points to one of the “FOR or LET” bindings in the XQuery FLWOR expression. The first result, the node locations pointed to by the cursors is returned by the program code.
The program code is further adapted to advance the inner cursor along the match graph in reverse binding order, responding to the advancing inner cursor pointing to a step match by returning subsequent result sets, and when the inner cursor doesn't find a match step by advancing an outer cursor in reverse binding order. The outer cursor is advanced in a similar manner and additional node sets are returned.
Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present invention should be or are in any single embodiment of the invention. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, discussion of the features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.
Furthermore, the described features, advantages, and characteristics of the invention may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the invention may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the invention.
These features and advantages of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.
In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:
Many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like.
Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.
Reference throughout this specification to “one embodiment”, “an embodiment”, or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment”, “in an embodiment”, and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
Reference to a signal bearing medium may take any form capable of generating a signal, causing a signal to be generated, or causing execution of a program of machine-readable instructions on a digital processing apparatus. A signal bearing medium may be embodied by a transmission line, a compact disk, digital-video disk, a magnetic tape, a Bernoulli drive, a magnetic disk, a punch card, flash memory, integrated circuits, or other digital processing apparatus memory device.
Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
An XML Pivot Join provides an efficient way to filter a collection of XML Documents for documents that satisfy some XPath/XQuery expression. For example, given XPath /a/b[c=5 and d=6] and a collection of XML documents. In certain embodiments, the XML Pivot Join method performs index ‘ANDing’ on two XML Index Scans, one XML Index scan on /a/b/c=5 and one XML Index scan on /a/b/d=6. In this case, the XML Pivot Join method advances the scans of one leg based on the location information of scans of another and vise-a-versa. If the scan on /a/b/c=5 returns the location document 5 nodeID 1.1.2.3 (saying that document 5 has a path a-b-c such that c's value is 5, then the next location we need to look for to satisfy the expression /a/b/d=6 has to be at least at document 5 and below that a-b path at document 5 (since we're looking for a a-b-d path where d's value is 6). If the node c on the a-b-c path that satisfied /a/b/c=5 at document 5 has the nodeID of 1.1.2.3, then the nodeID of b for the a-b path is 1.1.2. This means the scan for /a/b/d=6 has to start at least at the location document 5, nodeID 1.1.2. Intuitively this means that since we've found a a-b-c path at document 5, we need to look for a d under that a-b path under document 5 where the a-b-d path=6. If we find a match for /a/b/d=6 at document 5 nodeID 1.1.2.4 for instance, then we've found a document that satisfies /a/b[c=5 and d=6]. If the next location for /a/b/d=6 is some node at document 7, then the index scan for /a/b/c=5 now needs to be advanced to some location at document 7, so the algorithm advances either of the legs until a matching document location and node location is found.
We will now describe in detail how XML Pivot Join filters XML documents given some regular XPath expression, and in the process describe the necessary structures used in XML Pivot Join.
Refer first to
//x[.//v[b=‘b’ and c=‘c’] and .//a=‘a’ Expression 1:
The double lines in query tree 200 represent the descendant axis steps and the single lines represent child axis steps.
A paths table corresponding to document 1 (10), document 2 (20), document 3 (30), document 4 (40), and document 5 (50) is listed below. The Paths Table uniquely identifies all the Paths that exist in a collection of XML documents. For the example documents of
Now reference
1. //x[.//v[b=“b”]], which is XPath //x//v/b
2. //x[.//v[c=“c”]], which is XPath //x//v/c
3. //x[.//a=“a”], which is XPath //x//a
From these linear XPaths, we find matching paths in the paths table. The paths found are used to build the paths tree 300, which shows matching paths for each linear XPath and shows where paths may have common ancestors in the collection of documents. For example, the path z-e-x-p-v-b, which matches linear XPath //x//v/b, shares a common path segment z-e-x-p-v with the path z-e-x-p-v-c, which matches linear XPath //x//v/c. This means there may be some set of paths z-e-x-p-v-b z-e-x-p-v-c within the collection of documents whose location at z-e-x-p-v matches (e.g. the /b and /c match have a common //v match).
For each linear XPath in the query, we will also create XML Index Entries. For the linear XPaths
1. //x[.//v[b=“b”]], we will create XML Index entries based on the XPath //x//v/b,
2. //x[.//v[c=“c”]], we will create XML Index entries based on the XPath //x//v/c,
3. //x[.//a=“a”], we will create XML Index entries based on the XPath //v//a.
Entries for the XML Indexes are shown below, in Table 2. The fields in each entry contain:
1. Path—the unique path that matched some linear XPath,
2. Value—the value of the last document node in the path,
3. DocID—the document id of the XML document that contains the Path in (1),
4. NodeID—the id of the node in the XML document that is in the Path in (1).
The XML Index Entries record Path, Value pairs where the Path describes some Path in some XML document, and the value of the node (as a result of Atomization) at the end of the Path. The DocID refers the XML document containing the path, and NodeID refers to the location of the node at the end of the Path. The XML Index Entries describes the XML documents that have some Path and Value in ascending DocID and NodeID order.
Refer now to
The XML Index Entries, shown in Table 2, relate to locations within the collection of XML documents, shown in
Refer now to
Using the illustration above for example, we can easily see the matches for the linear XPath //x//v/b. That is, we have the matching paths b1 at document 1, b3 at document 1, b1 at document 2, and so on. For the linear XPath //x//v/c, we have the matching paths c1 at document 1, c3 at document 1, c2 at document 2, and so on. For the linear XPath //x//a, we have the paths a2 at document 2, a2 at document 3, a4 at document 4, and so on. We will then describe the way the Pivot Join method advances the XML Index Cursors by saying that the b1 Index Cursor is currently at the first b1 in document 1, then at the first b1 at document 2 and so on.
We noted earlier that the Paths Tree shows that there may be some paths that share some ancestor path with other paths. The Pivot Join discovers whether documents do have paths that share ancestor paths by remembering Locations of Paths within the XML documents. The Pivot Join does this using the Match Graph. From the Query Tree and the Paths Tree above we can construct the Match Graph.
The Match Graph is constructed from the Query Tree and Paths Tree by finding paths in the Paths Tree that match Steps in the Query Tree. The b1 node in the Match Graph for example signifies the match between the b1 Path in the Paths Tree and the ‘/b’ step in the Query Tree. The Match Graph is used to remember document and node locations while performing the XML Index Cursor scans. For example, if we advance the index scan for b1 and it returns document 1 and nodeID for the first b1 in document 1, we will remember that the location, document 1 and the nodeID for the b1 match in the Match Graph node b1.
We say that the Match Graph node b1 is at location document 1 and nodeID of the b1 node in document 1.
Note that the non-leaf nodes in the Match Graph such as v1, v2, and x1 also contain location information for the //v, //v and //x matches respectively and their locations come from the truncated locations of their descendant leaf match nodes.
For the sake of brevity in the following discussions, we will sometimes omit saying what nodeID we are at in the match graph nodes, because the reader can easily see which document nodes are being referred to in the XML Documents diagram. Pivot Join uses one Index Cursor for each leaf in the Match Graph. Each leaf node in the Match Graph refers to a unique path that matched a linear XPath in the query tree. So the b1 match has one Index Cursor, c1 path has one Index Cursor; b2 path has one Index Cursor, and so on. This allows us to advance each Index Cursor for their respective Path entries in the Index in docID, nodeID order.
Now that we've described the Paths Tree and the Match Graph, we will describe how Pivot Join works. The following examples show snapshots of the Match Graph and describe how Locations (based on docID and nodeID) are computed.
We will show how the index scans are advanced based on the locations computed and we will use the XML Documents Diagram below to help track what the Index Cursors are pointing to.
The snapshots of the Match Graph below progress from left to right. The leaves of the Match Graph correspond to index scans. In the Match Graph snapshot to the left, the b1 index scan is at doc1 (document 1). The c1 index scan is also at doc1. b2 at doc2, c2 doc2. a1 at doc5 and so on. The locations in the match graph nodes show that the b1 index scan is at document 1, the c1 index scan is at document 1, the b2 index scan is at document 2, the c2 index scan is at document 2, the al index scan is at document 5, and so on. The reader should be able to follow the index scans by referencing the XML Documents Diagram above. Although not shown in the diagram, the b1 match node not only remembers that it is currently at doc 1, but also that it is at the first b1 path in document 1 using that b1's nodeID. Again, for brevity, we won't mention the nodeID part of the location where it is obvious from the XML Documents Diagram.
Given the locations computed for the leaves of the Match Graph above, we now need to compute for the locations of the ancestor match nodes. The XML Pivot Join Algorithm does this by computing the locations of the ancestor match nodes bottom up. That is, we need to compute for the location of v1 above the b1 and c1, and then later x1 above the v1, and so on. We compute for the locations of the ancestors by truncating the nodeIDs of their descendant match nodes to the levels of the ancestors match node, and applying the following rules.
In the Match Graph snapshot to the right, we truncated b1's nodeID location to v1's level and find that the nodeID equals the nodeID computed by truncating the nodeID of c1 to v1's level. We also find that the docIDs for b1 and c1 are equal. So we are Exact at v1. We depict this condition with an asterisk (*) at v1 (rule 1). This reflects the fact that a b1 path and a c1 path have the same v1 ancestor in document 1. Here v1's nodeID is the truncated nodeID of b1 at doc1. We can derive the same discussion for v2.
To compute for x1's location, we take the min of (a1, a2) and min(v1, v2) (rule 3), then apply rule 1 or rule 2. Just considering the docIDs for now, we can see that (min(a1,a2), min(v1, v2)) is equal to (min(doc5,doc2), and min(doc1, doc2)) is equal to (doc2, doc1). Because doc2 is not equal to doc1, we take the maximum (rule 2), so x1 is now at doc2 with a2's nodeID truncated at x1's level.
We show in the snapshot to the right, that x1's location is doc2 and that x1 is NotExact (represented by the absence of the asterisk (*)). To compute for z's location, we take the min of (x1 and x2), so z is at doc2 and is NotExact. z represents the location of the first element of the document. Because z is NotExact, we need to try to advance the cursors again until z becomes Exact. If z becomes Exact, it means we've found a XML document that matches the XPath query. Given rules 1, 2, and 3, z can only become Exact if some path along the Match Graph from descendant matches to z are all Exact.
To advance the cursors, we Pivot at the z match node (which happens to be the minimum location for the z step) by incrementing the location of z to a location just before the next sibling of z. Intuitively, since each match node is a match of a step at a specific level, the next possible match for z at that level would have to be its next sibling. The Pivot at the z match node is depicted below with the plus sign+next to the doc2 location at the z match node. The Pivot is computed so that some index cursors can advance beyond their current locations. Next the b1 index cursor will be advanced from its current location. Specifically, the next location of b1 will be computed by taking the maximum of all b1's ancestor matches, after taking the minimum of matches for the same step, which is max location of (b1, min(v matches), min(x matches ), and z+), which is max(b1, v1, x1, z+)==z+.
Using z+ as the key for the index lookup on b1, we will get doc3 as the next location for b1.
The match graph above and to the left now, shows that we advanced the b1 index cursor to doc3 (specifically we advanced b1 to the first b1 at doc3). By advancing b1 to doc3, and then applying the algorithm described to get locations for ancestor match node locations (rules 1-3), we can derive the match graph to the right and we're now able to find a match at x1 in doc2. That is, we've found a b2 path and a c2 path with the same v2 ancestor, and the v2 and a2 has the same x1 ancestor at document 2. In this case, z will be Exact. The doc2 location computed at z is the first match for the query //x[ .//v[b and c] and .//a ]. This can be easily confirmed with the Documents Diagram below.
After we've returned our first answer (doc2), we can again Pivot at z and advance the cursors as depicted below with the match graph to the left. After advancing some cursors, some locations will reach end-of-file (EOF) as depicted with b3, v3, and c3 as they've moved past doc1 which is the last document where these paths exist. For the purpose of computing the locations, EOF is always higher than any location. After advancing a4's location beyond doc4 as depicted in the match graph to the right, we find an Exact in x2 and z in document 5. This is the second match of for the query //x[ .//v[b and c] and .//a] found in document 5.
As shown in the discussions above, XML Pivot Join takes the index cursors to the first locations within XML Documents that satisfy the query, then returns the docID of the document that qualified using the first match node in the match graph (the z match node). (In fact, it is the docID and the nodeID of the z match node that is returned. But since there should only be one z in the XML document, we are effectively just returning the docID of the XML document.). In the previous examples, we returned doc2, and then doc5 using the location stored in the z match node. After we return the docIDs of qualifying documents, we Pivot at the z node and advance the cursors again to look for the next qualifying document. XML Pivot Join allows us to perform inter-document filtering for a collection of XML documents.
The present invention extends the state of the art beyond the XML Pivot Join procedure described above in order to enable intra-document level filtering and to return multiple locations as tuples of locations within a document. For example, consider the sample XQuery FLWOR expression of Expression 2.
for $x in doc( )//x Expression 2:
Assume that an XML document has been preselected from a collection of XML documents based on its containing at least one subtree that matches the sample XQuery. One particularly suitable method for accomplishing such a preselection has been described above.
In order to find all matching sub-trees within the preselected XML document, the ‘pivoting’ procedure described above is modified so that the procedure pivots at specific match nodes that correspond to matches to step nodes in the XQuery rather than pivoting at the z match node so we can avoid jumping ahead to the next matching document. For example, in the FLWOR expression shown in Expression 2, the step nodes in the query are the //x, //v, /b, /c and //a steps. The match graph for this query can have multiple Match Nodes corresponding to unique paths that match the //x, //v, /b, /c, and //a steps. In the following discussions, forward binding order refers to the order specified in the query (read top to bottom and left to right), which is //x, //v, /b, /c and then //a. Reverse binding order then is //a, /c, /b, //v, //x.
To show that the algorithm works, we will first show how the index scans need to be positioned within the xml document so that we can return the correct results. Referring first to
In the following discussions, we will explain how we advance the index scans corresponding to match nodes. For example, to advance the index cursor for a2, we will say that we will Pivot a2 to some location. This location will be expressed either as (a21+<Pivot<x1+) or (x1<Pivot <x1+). To explain this notation, a21 means the a2 path in the document that is the 1st match for the //a step. a21+then means the location just before the next sibling of the a21. (a21+<Pivot <x1+) means that Pivot is a location greater than the location just before the next sibling of a21, but less than the location just before the next sibling of x1. In other words, Pivot is the location after a21 but under x1, which we will use to find the next //a match under the //x match. (x1<Pivot <x1+) means that Pivot is a location after x1 but before the location before the next sibling of x1. In other words, Pivot is the location under x1 but not after x1, which we will use to find the first //a match under a //x match. Note that
Refer now to
To obtain Answer 3, we Pivot the //a matches to (a22+<Pivot<x1+). Since there are no more //a matches under x1, we get End-of-File (EOF) for //a. Because we got EOF we will now Pivot the next step in reverse binding order, which means we will Pivot on /c matches. We will now Pivot on /c matches under the //v match v21. We will Pivot c2 to (c21+<Pivot<v21+). There are no more /c matches under v21 so we get EOF for the /c step. The next step in reverse binding order is /b so we will now Pivot in /b matches under v21. We will Pivot b2 to (b21+<Pivot<v21+). Again there are no more /b matches under v21 so we get EOF for the /b step. Next in reverse binding order is the //v step. To Pivot on the non leaf step //v (which means we're pivoting on either v1 or v2 matches under the x1), we need to Pivot on any of the //v descendant leaf matches (the matches for /b and /c steps). This includes b1, c1, b2, and c2 in the match graph. To Pivot //v means we will Pivot on any of b1, c1, b2, c2 to (v21+<Pivot<x1+).
Referring now to
In (5), in reverse binding order, we will Pivot on the matches for the //a Step under the current //x match. So we will Pivot a2 to (a21+<Pivot<x1+). In (5), we can return the fourth result. In (6) we pivot a2 and reach EOF then pivot c1 and reach EOF. In (7) we pivot b1 and reach b13. Because b13 is non-EOF, we will now pivot in forward binding order and pivot /c and //a matches. In (7), we position c1 and a2 to c12 and a21 respectively. In (7) we can return the fifth result. In (8), in reverse binding order, we pivot a2 to a21, and we can return the sixth result.
Refer now to
Based on the descriptions of the algorithm for Multiple Extractions Pivot Join, we outline the observations listed below.
First Observation: When Pivoting the matches in reverse binding order, we advance the matches to a location > the location before its next sibling and < the location before the next sibling of the current ancestor match. Note that advancing the matches to the XML Pivot Join may advance a match beyond the location of another match for the same step, and if this is the case, we always take the minimum location after the Pivot (you can see this happening with //v matches above when we Pivoted to v12 from v21, which could have been because the next location of v2 is > than that of v1 but still under the same x1, rather than v2 reaching EOF).
The ancestor match to consider here is the least common FOR ancestor step match. In this query for example, ‘for $a in doc( )/a, for $b in $a/b, for $c in $b/c return <r>{$b, $c}</r>’, /c's least common FOR ancestor is /b, but for ‘for $a in doc( )/a let $b in $a/b, for $c in $b/c return <r>{$b, $c}</r>’, /c's least common FOR ancestor is /a.
Second Observation: When Pivoting the matches in forward binding order, we advance the matches to a location ‘greater than’ (>) the location of the current ancestor match and less than (<) the location before the next sibling of the current ancestor match. The ancestor match to consider here is again the least common FOR ancestor step match. This produces the rewinding required in the query as the query finds the first match of a step under the ancestor step.
Third Observation: When Pivoting in forward binding order, if the index lookup reaches EOF, we need to reverse directions and do Pivoting in reverse binding order. This intuitively makes sense because we need to find other bindings based on previous bindings.
Fourth Observation: When Pivoting in reverse binding order, if the index lookup reaches EOF, we need to continue Pivoting in reverse binding order until the index lookup doesn't reach EOF, then we reverse directions and do Pivoting in forward binding order. If we reach the last step in reverse binding order and still reach EOF, we are done with intra-document Pivot Join. We can switch to doing inter-document Pivot Join again by Pivoting at the first element match of the document.
Fifth Observation: This intra-document filtering procedure can advantageously be accomplished immediately after an inter-document Pivot Join. For example, we can immediately start Pivoting in reverse binding order.
Sixth Observation: The Match Graph provides a very efficient mechanism for choosing which index scans to Pivot on to find the next results for a query. For example, when pivoting /b matches under a current //v match say v1, only b1 needs to be pivoted and not b2 because b2 belongs to a different //v match which is for a different v path.
In a further embodiment of the present invention, Recursive Matches within the preselected XML document are handled. Recalling Expression 2, our example XQuery expression:
for $x in doc( )//x Expression 2
Those skilled in the art will appreciate that there will be cases where there are multiple current ancestor matches to consider, during intra-document level filtering. This happens when there are descendant steps in the query and the matching document has recursive tags in them as in the case below for the ‘x’ tag.
Refer now to
The Match Graph for the document depicted in
As shown in
Right after Answer 4, we will reach EOF when we pivot at v1, so the next binding to Pivot in reverse binding order are the matches for //x. Since there are currently 2 //x matches, we will Pivot from x11 to x21 for the //x step based on the Pivot (x11+<Pivot<z+). x1 will reach EOF but x21 will be the new minimum match for //x step.
Refer now to
Refer now to
In yet a further embodiment of the present invention, Sequences and EOE Issues within the preselected XML document are handled. Again recalling Expression 2, our example XQuery expression:
for $x in doc( )//x Expression 2
Refer now to
Note that we can only do this for queries that do not require EOE (empty on empty) semantics. That is, if there are no /b matches under a //v match for example, and we still want to return the /c matches under the //v (resembling outer join semantics) then we cannot use XML Indexes (and Pivot Join for that matter) to answer those queries.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.