[Monetdb-developers] [XQ] Mixing update/docmgmt/query

Ying Zhang Y.Zhang at cwi.nl
Tue Mar 18 15:14:08 CET 2008


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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-developers





More information about the developers-list mailing list