Abstract: Data used and generated by the process of validating XML documents is divided into two categories: compile-time static data and runtime data. Runtime data may be specific to a particular XML document and changes when validating the XML document, while compile-time data does not change in this way. For example, compile-time data may be data that defines, according to a schema, the descendant elements and ordering between them. Runtime data is information generated to track which descendants occurred in a particular XML document being validated. Compile-time static data, once generated to validate a particular XML document, is cached within a shared volatile memory. Once the compile-time data is cached, the compile-time static data may be used to validate other XML documents without the need to regenerate the compile-time static data.

Abstract: A database system may perform a streaming evaluation of an XPath expression by utilizing an XPath evaluation component in tandem with an XML event-streaming component. For a more optimal filtered streaming evaluation, the XML event-streaming component may provide an interface whereby the evaluation component sends certain criteria to the event-streaming component when requesting an XML event. The criteria may be based on a next unmatched step in the XPath expression. In response to the request for an XML event, the event-streaming component may only return events that match the criteria. The evaluation component may be, for example, a compiled state machine for the XPath expression. The criteria may be pre-compiled for each possible state in the state machine. The event-streaming component may also utilize the criteria along with schema information to skip parsing of certain segments of XML data.

Abstract: The approaches described herein provide an efficient way to process certain kinds of queries that retrieve XML data stored in an object-relational database. A technique determines whether a query comprises a plurality of iteration expressions that exhibit a particular relationship to one another, and if so, re-writes the query and produces an optimized query execution plan. The query execution plan specifies an XPath-based row source with caching enabled. A very small cache structure is used, and reference locators are stored in the cache that point into binary-encoded data rather than copying XMLType data into the cache. Row data may be cached on the first use of the path-based row source and re-used in subsequent requests for rows. Once there is a subsequent request for rows from the optimized path-based row source, the cache may be reorganized to efficiently produce the rows of the row source.

Abstract: A method and system for the in-place evolution of XML schemas is disclosed. To automatically evolve an existing XML schema, a schema evolver receives both an existing XML schema and an XML document as input. The XML document indicates changes to be made to the existing XML schema. Based on the existing XML schema and the XML document, the schema evolver evolves the existing XML schema into a new XML schema that incorporates the changes indicated in the XML document. According to one aspect, the schema evolver generates one or more SQL statements based on the new XML schema. The SQL statements, when executed by a database server, cause the database server to evolve database structures that were based on the formerly existing XML schema so that the database structures conform to the new XML schema. This is accomplished “in place,” without copying the data in the database structures.

Abstract: Techniques are described herein for efficient and scalable processing of complex sets of XML schemas. The techniques described herein provide for reducing duplication of schema elements in volatile memory by building an XML schema in-memory model that stores repeating schema elements in in-memory data structures that are separate from in-memory data structures that store the parent schema elements which logically include or otherwise refer to the repeating schema elements. The techniques described herein also provide for faster generation of an in-memory model of an XML schema by pre-loading, in data structures on persistent storage, of schema elements from dependent XML schemas that are referenced and/or incorporated by the XML schema.

Abstract: Techniques are provided to achieve performance improvements for path-based access to hierarchical data and for utilizing an extensible indexing framework. Extensible operators may be optimized by evaluating the operators using functions native to the database system instead of using functions defined through an extensible indexing mechanism. Furthermore, the database system may resolve a resource path of a query when the query is compiled, and may store the mapping of the resource path to one or more resources in a cursor for the query execution plan to avoid resolving the resource path each time the cursor is used to run the query. The cursor may be made dependent on the one or more resources to which the resource path refers at compile time. This takes advantage of the observation that the mapping of the resource path to particular resources rarely changes between evaluations of a particular query.

Abstract: Techniques are provided for estimating the cardinality of a virtual result table that is produced by executing path-based table functions within a query, such as the XMLTABLE function. Some path-based table functions apply a path expression to input from a base table of XML documents to select rows to produce the result table. Path statistics are collected for the path expressions for the base table. The path statistics are used to estimate the cardinalities of the result table. The estimated cardinality of the result table is useful for estimating costs of query execution plans that are generated for the query.

Abstract: A method for storing XML documents a hybrid navigation/streaming format is provided to allow efficient storage and processing of queries on the XML data that provides the benefits of both navigation and streaming and ameliorates the disadvantages of each. Each XML document to be stored is independently analyzed to determine a combination of navigable and streamable storage format that optimizes the processing of the data for anticipated access patterns.

Abstract: A method and apparatus for performing an action in response to a file system event is provided. According to one aspect, sets of “event listeners” are associated with a file hierarchy and/or the nodes thereof. Each event listener contains a set of “event handlers.” Each event handler corresponds to a separate type of event that may occur relative to the file hierarchy's nodes. When an event is going to occur relative to the hierarchy or a node thereof, all event listeners that are associated with that hierarchy/node are inspected to determine whether those event listeners contain any event handlers that correspond to the event's type. Those event handlers that correspond to the event's type are placed in an ordered list of event handlers to be invoked. As the event handlers in the list are invoked, programmatic mechanisms that correspond to those event handlers are executed to perform customized user-specified actions.

Abstract: The approaches described herein provide an efficient way for a database server to process certain kinds of queries over XML data stored in an object-relational database that require the evaluation of a predicate expression with one or more path-based operands. A predicate expression part of a XQuery or SQL WHERE clause that returns a boolean value. A database server first determines whether the query qualifies for this particular kind of optimization, then rewrites the query using an enhanced query operator syntax for specifying the predicate expression to be evaluated. The enhanced query operator subsumes the work of a second path-based query operator, resulting in the suppression of the WHERE EXISTS subquery. The rewritten query operator is used to generate a query execution plan that provides for several query execution optimizations.

Abstract: A modular repository is described, where operational features may be implemented without the need to scan every resource included in the modular repository. A modular repository includes a dedicated set of database objects containing all information needed to access the resources in the repository. For example, the database objects of a modular repository may include those user identifier mappings and ACL mappings, etc., to which metadata in the modular repository refers. A database system may also include a mechanism through which a modular repository may be mounted under a subdirectory of a common directory in the database system. The resources of a modular repository that are mounted under the common directory may be accessed through the common directory. Further, a client may query the resources of any modular repository mounted under the common directory by making the federated repository, represented by the common directory, the context of the query.

Abstract: A modular repository is described, where operational features may be implemented without the need to scan every resource included in the modular repository. A modular repository includes a dedicated set of database objects containing all information needed to access the resources in the repository. For example, the database objects of a modular repository may include those user identifier mappings and ACL mappings, etc., to which metadata in the modular repository refers. A database system may also include a mechanism through which a modular repository may be mounted under a subdirectory of a common directory in the database system. The resources of a modular repository that are mounted under the common directory may be accessed through the common directory. Further, a client may query the resources of any modular repository mounted under the common directory by making the federated repository, represented by the common directory, the context of the query.

Abstract: Business logic is integrated within a repository through the use of “resource configurations.” A resource configuration is a unit of business logic that is supplied by a user to the repository and associated with a particular directory and/or a resource. Each resource configuration contains one or more configuration items that each defines and/or expresses one or more business rules for managing a resource associated with the resource configuration.

Abstract: Techniques are provided for ensuring lexical fidelity when an XML document is stored in a binary format. Operations, on the XML data, that would cause the loss of lexical fidelity between the original XML document and the binary-encoded version of the XML document are not performed. Such operations include the removal of unnecessary whitespace characters, certain data type conversions, CRLF normalization, the “collapsing” of two-tag empty elements into a single tag empty element, and the replacing of entity references or numeric character references with another value. An XML schema, to which the XML document conforms, may indicate that the XML document is to be stored in a lexical fidelity mode. Additionally, or alternatively, the database statement that (when executed) causes the XML document to be stored in a binary format may so indicate.

Abstract: A mechanism is provided for improving the performance of particular database queries operating on a view comprising binary-encoded XML. A determination is made about whether a XML index is available to improve the computation of XPath data before deriving an optimized execution plan for a particular query. When a XML index is not available to help expedite the computation of binary-encoded XML, then deferring the computation of the XPath data until after the view merge stage avoids unnecessary computation of XPaths that are part of the view but not needed for the particular query.

Abstract: Techniques for estimating the cost of processing a database statement that includes one or more path expressions are provided. One aspect of cost is I/O cost, or the cost of reading data from persistent storage into memory according to a particular streaming operator. Binary-encoded XML data is stored in association with a synopsis that summarizes the binary-encoded XML data. The synopsis includes skip length information for one or more elements and indicates, for each such element, how large (e.g., in bytes) the element is in storage. The skip length information of a particular element thus indicates how much data may be skipped during I/O if the particular element does not match the path expression that is input to the streaming operator. The skip length information of one or more elements is used to estimate the cost of processing the database statement.

Abstract: A technique and mechanism for efficiently searching across multiple versions of a resource is provided. New operators are provided that take into account the versions of a particular resource. The query engine evaluates the new operators using either an index-based approach or a functional approach. Under an index-based implementation, a hierarchical index is traversed to find a particular resource (or resources) associated with a specified path and the version history identifier associated with the particular resource(s). A version history table containing references to all versions of the particular resource(s) are then obtained. Under the functional implementation, a link table, which contains all paths in a user's workspace, is examined to determine whether the version history identifier of a particular resource matches a version history identifier of a resource specified in the link table and whether the path to the resource in the link table is related to the path specified.

Abstract: Techniques for fast and scalable generation and aggregation of XML data are described. In an example embodiment, an XML query that requests data from XML documents is received. The XML query is evaluated to determine one or more XML results. For each particular XML result, evaluating the XML query comprises: instantiating a particular data structure that represents the particular XML result, where the particular data structure is encoded in accordance with tags specified in the XML query but does not store the tags; and storing, in the particular data structure, one or more locators that respectively point to one or more fragments in the XML documents, where the particular data structure stores the one or more locators but does not store the one or more fragments. On demand, in response to a request indicating the particular XML result, a serialized representation of the particular XML result is generated based at least on the particular data structure.

Abstract: Data used and generated by the process of validating XML documents is divided into two categories: compile-time static data and runtime data. Runtime data may be specific to a particular XML document and changes when validating the XML document, while compile-time data does not change in this way. For example, compile-time data may be data that defines, according to a schema, the descendant elements and ordering between them. Runtime data is information generated to track which descendants occurred in a particular XML document being validated. Compile-time static data, once generated to validate a particular XML document, is cached within a shared volatile memory. Once the compile-time data is cached, the compile-time static data may be used to validate other XML documents without the need to regenerate the compile-time static data.

Abstract: Techniques are described herein for efficient and scalable processing of complex sets of XML schemas. The techniques described herein provide for reducing duplication of schema elements in volatile memory by building an XML schema in-memory model that stores repeating schema elements in in-memory data structures that are separate from in-memory data structures that store the parent schema elements which logically include or otherwise refer to the repeating schema elements. The techniques described herein also provide for faster generation of an in-memory model of an XML schema by pre-loading, in data structures on persistent storage, of schema elements from dependent XML schemas that are referenced and/or incorporated by the XML schema.