<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="changes" page="intro91" subpage="xqupdate91"/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: XQuery Updates</title>
<meta name="coverage" content="Worldwide"/>
<meta name="copyright" content="Copyright Saxonica Ltd"/>
<meta name="title" content="Saxonica: XSLT and XQuery Processing: XQuery Updates"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>XQuery Updates</h1>
<p>Saxon 9.1 introduces support for XQuery Updates.</p>
<p>To run an updating query from the command line, use the option <code>-update:on</code> on the command line.
From Java, compile the query in the normal way, and use the method <code>XQueryExpression.runUpdate()</code> to
execute the query. At present it is not possible to run updates using the higher-level interfaces in XQJ or S9API,
or using the .NET API.</p>
<p>To enable updating internally, an extension of the <code>NodeInfo</code> interface has been introduced, called
<code>MutableNodeInfo</code>. Currently the only tree implementation that supports this interface is the linked tree
(formerly called the standard tree). In principle updating should work with any tree model that supports this
interface, though at present there are probably some dependencies on the specific implementation.</p>
<p>The linked tree has been improved so that it can now handle schema type annotations, and there have been improvements
to the way in which line number information is maintained.</p>
<p>Saxon does not currently include any locking code to prevent concurrent threads attempting to update the same document.
This is something that applications must organize for themselves.</p>
<p>At the Java API level, updated documents are not automatically written back to disk. Rather, the <code>runUpdate()</code>
method returns a set containing the root nodes of documents that have been updated. This may include documents that were read
using the doc() or collection() functions as well as documents supplied as the context node of the query or by binding
external variables. It may also include documents (or elements) that were created by the query itself - but only if they have
been updated after their initial construction. There is a helper method <code>QueryResult.rewriteToDisk</code> allowing such
documents to be written back to disk if required, at the URI determined by their <code>document-uri()</code> property,
but this must be explicitly invoked by the application. Clearly if the application does not have write access to the URI,
this operation will fail.</p>
<p>Alternatively, updated documents may be written back to disk using the <code>put()</code> function. Note that because
<code>put()</code> delivers no result, there is a danger that it will be "optimized out" of the query. Saxon implements
<code>put()</code> using the runtime code for <code>xsl:result-document</code>, and the implementation currently
imposes similar restrictions: in particular, it must not be called while evaluating a variable or function.</p>
<p>Applications should access the updated document via the root nodes returned by the <code>runUpdate()</code> function.
Use of <code>NodeInfo</code> objects that were obtained before running the update is in general unsafe; while it will probably
work in most cases, there are some cases (particularly with attributes) where the <code>NodeInfo</code> object returned to the
application is a snapshot created on demand, and this snapshot will not be updated when the underlying tree is changed.</p>
<p>Updates are not currently atomic, as required by the specification. In particular, if the update fails revalidation
against the schema, it is not rolled back.</p>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="schema11support91.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
