On Mar 18, 2008, at 14:43 , Keulen, M. van (Maurice) wrote:
Hi,
I know that the XQUF prohibits it, but for writing robust functions, it is often necessary to mix query and update/docmgmt functionality. Some examples: • Expression that queries/updates document, but if the document does not exist, adds an empty version of it: let $name := "foo.xml" let $emptydoc := <root/> let $doc := if (empty(pf:documents()[.=$name])) then (put($emptydoc, $name),$emptydoc) else doc("foo.xml") return $doc//bar • Expression that adds to a log-file: let $log := doc("log.xml") let $expr := ...some expression... return (do insert <entry>...{$expr}...<entry> as last into $log,$expr) Each of these patterns gives you a "!type error: err:XUST0101: illegal mix of updating and non-updating expressions" error.
Isn't is possible to somehow allow such expressions? It is against the standard, so it probably requires some server configuration parameter, but it would be really really useful to have it. Mixing queries with update/docmgmt is known to cause many semantical problems, but only if these updates are visible within the query. Looking at the implementation based on pending update lists, then each of these patterns is harmless. If you declare that no updates are visible within the transaction (which is against the standard), then allowing these queries is I guess not hard: it simply means that with updating expressions and document management expressions you do return a result.
Another thing I've been thinking about in this context: If I send two SOAP-messages to a server on its XRPC-port, am I guaranteed that they are served in the same order? I could perhaps, with a lot of duplication of code, separate update/docmgmt from a query, i.e., implement these things with two requests to the server. I really dislike such a solution, though.
Hi Maurice, I assume you are talking about soap msgs triggered by execute-at statements in your query, then, it depends on where those execute-at statements are in the query. If they are in a sequence expression: (execute at {peer1} {fcn1()}, execute at {peer1} {fcn2()}), then fcn1() will always be evaluated firstly, and then fcn2(). If they are in a for-expression: for $dst in ("peer1", "peer2") return execute at {$dst} {fcn1()}, then the request messages will be sent *in parallel* to peer1 and peer2. Hence, if peer1 and peer2 happen to be the same peer (e.g. if you address the same peer by its hostname, and its ip-address, the xrpc client won't know that the destination is actually the same peer, because xrpc client only does simple string comparison to find unique destination), the order in which the messages are handled depends on which one arrives first. But the order of the results of the for-loop is guaranteed to conform the iteration number. Regards, Jennie
Looking forward to comments :-)
Maurice.
-- ---------------------------------------------------------------------- Dr.Ir. M. van Keulen - Assistant Professor, Data Management Technology Univ. of Twente, Dept of EEMCS, POBox 217, 7500 AE Enschede, Netherlands Email: m.vankeulen@utwente.nl, Phone: +31 534893688, Fax: +31 534892927 Room: ZI 3039, WWW: http://www.cs.utwente.nl/~keulen ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_____________________... Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers