The collection
configuration elements cannot be specified
system-wide.
XML Databases
- 1. Introduction
- 2. Tamino XML Server 4.1
- 2.1. Configuration
- 2.1.1. config Input
- 2.1.2. System-Wide Configuration
- 2.2. Queries
- 2.2.1. data Input
- 2.2.2. data Output
- 2.2.3. X-Query Example
- 2.2.4. XQuery Example
- 2.3. Insertions
- 2.3.1. data Input
- 2.3.2. Example
- 2.4. Deletions
- 2.4.1. data Input
- 2.4.2. Example
- 2.5. Updates
- 2.5.1. data Input
- 2.5.2. Example
- 2.6. Transactions
- 2.1. Configuration
- 3. XML:DB Databases (eXist)
1. Introduction
XML databases allow you to easily store, index and query XML documents. They are especially useful when dealing with document-centric applications, where the structure cannot be mapped naturally to a relational database.
OPS integrates with Tamino XML Server databases, as well as XML:DB databases such as eXist.
2. Tamino XML Server 4.1
Software AG's Tamino provides a complete XML storage solution. OPS allows you to easily store, query, update, and delete documents in Tamino. The following sections describe the four OPS processors for Tamino.
2.1. Configuration
All Tamino processors have a common config
input, describing the
database connection and collection.
The configuration of the Tamino processors can be done in two ways: either
system-wide via the OPS
Properties, or locally for a specific instance of the processor through
the config
input. The local configuration takes precedence if
available.
2.1.1. config Input
The config
input document specifies the URL of the Tamino
server, the credentials to use when connecting and the collection to
access. The following table describes the configuration elements.
Name | Description |
---|---|
url
|
Tamino database URL. |
username
|
Username to authenticate with the server |
password
|
Password to authenticate with the server |
collection
|
XML Collection to use |
This RelaxNG schema describes the expected document.
2.1.2. System-Wide Configuration
The Tamino processors can be configured in the OPS properties file, allowing all instances to share the same configuration. The following processor properties are allowed:
Name | Type | Description |
---|---|---|
url
|
anyURI
|
Tamino Server URL. |
username
|
string
|
Username to authenticate with the server. |
password
|
string
|
Password to authenticate with the server. |
These properties are set as follows:
The following global properties are allowed:
Name | Type | Description |
---|---|---|
oxf.tamino.isolation-degree |
string |
Isolation degree. Possible values are:
uncommittedDocument , committedCommand ,
stableCursor , stableDocument ,
serializable . See the Tamino documentation for more
details on the isolation degree.
|
oxf.tamino.lock-mode |
string |
Lock mode. Possible values are unprotected ,
shared , protected . See the Tamino
documentation for more details on the lock mode.
|
These properties as set as follows:
2.2. Queries
The oxf:tamino-query
processor processes queries either using
Tamino's X-Query or W3C XQuery.
2.2.1. data Input
The data
input contains only the root element and the query.
The root element is either query
for an X-Query query, or
xquery
for an XQuery query.
2.2.2. data Output
The processor sends the result of the query in the data
output.
The root element is always result
.
2.2.3. X-Query Example
2.2.4. XQuery Example
2.3. Insertions
The oxf:tamino-insert
processor allows you to insert a document in
Tamino.
2.3.1. data Input
The
data
input contains the document to insert.
2.3.2. Example
2.4. Deletions
The oxf:tamino-delete
processor allows you to remove documents
from Tamino.
2.4.1. data Input
The data
input contains the X-Query to select the document(s)
to be removed.
2.4.2. Example
2.5. Updates
The oxf:tamino-update
processor allows you to update parts of
documents directly inside Tamino. An extension of XQuery is used for that
purpose. Refer to the Tamino documentation for more information.
2.5.1. data Input
The data
input contains the XQuery expression to update one or
multiple nodes.
2.5.2. Example
2.6. Transactions
OPS initiates a transaction for every HTTP request, and commits the transaction when the pipeline is executed normally. If an exception occurs in the pipeline, the transaction in rolled back.