If it is an update statement, then it isn't a query statement. You can use xdmp:invoke and its cousins to create a parent query (read-only) with child update statements in different transactions. This is a sharp tool, and is likely to cut. http://docs.marklogic.com/4.2doc/docapp.xqy#display.xqy?fname=http://pubs/4.2doc/xml/dev_guide/transactions.xml has more details. It is somewhat difficult to make this work: I think that's by design, to discourage using it unless absolutely necessary.
The performance cost of an update statement depends on the environment and on what the update does. Start with a read-lock for every fragment matched by the database queries in the statement. After that, there will be a write-lock for every fragment that is actually updated, plus journal writes and stand management. For a standalone host, the lock operations are in-memory and likely cheaper than any disk operations. In a cluster, the lock operations are relatively expensive, and more so as the cluster size grows. You may wish to experiment with a model using a separate module to apply a read-only function, while applying read-only functions directly. That approach sacrifices ACID, since the update takes place in a different transaction, but avoids many of the complications of same-transaction metaprogramming. To resolve the UPEXTNODES, use xdmp:path and xdmp:unpath. However, remember that you don't have ACID anymore. So you will not be able to guarantee that the selected node exists when the update commits. The only way to guarantee that is to run the entire operation in a single transaction, with locks. -- Mike On 20 Sep 2011, at 14:47 , Tim Finney wrote: > Dear List, > > I would like to use the xdmp:apply(xdmp:function(), ...) pattern in an > application. The functionality is mainly read-only, where an > unprivileged role (app-user) is allowed to search and display documents > in a database. However, I would also like to record user search strings > and to store feedback and errors in database documents. I would prefer > to always run the application as a query statement to avoid the > performance hit of running as an update transaction. > > Is there a way to run as a query statement and also allow the app-user > role to write to the database when using the > xdmp:apply(xdmp:function(), ...) pattern? How much of a performance hit > is incurred by running as an update? I have tried using an amped > function to log feedback as a distinct transaction but get a > "XDMP-UPEXTNODES Cannot update external nodes" error. > > Best, > > Tim Finney > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
