[Monetdb-developers] Monetdb-developers Digest, Vol 22, Issue 4

Ying Zhang Y.Zhang at cwi.nl
Fri Mar 28 14:54:08 CET 2008

On Mar 28, 2008, at 14:01 , Peter Boncz wrote:
> Hi Maurice,
> - what you want *really* is XQueryP, but we do not have resources to  
> give you
> that. The fact that we use the result sequence to pass on the update  
> tape
> actually makes it difficult to give back a result.
> - if you send two asynchronous requests, there is no guarantee that  
> one is
> executed after the other.
> - fn:put() is currently still an updating function, but this is  
> erroneous. I
> will check in a modification that makes it a readonly one (soon).

Hi Peter,

Before you change it, please have a look at the latest version of XQUF  
(http://www.w3.org/TR/xquery-update-10/).  In earlier draft version,  
fn:put() was (explicitly) specified as a read-only function, but this  
has been removed in the latest version and it *seems* to have become  
an updating function.

> Do I ready you correctly that this would already be enough? Notice  
> that fn:put()
> does not add a document to the database. It just creates some XML  
> file on the
> server.
> A very ugly hack that comes to mind is to support a special URI in  
> fn:put(),
> e.g. "xrpc://user-data"  that works only in a XRPC request, and  
> causes the node
> to be included in XRPC response message. Not as the result sequence,  
> but in some
> optional user-data section.
> A more elaborate hack would be to allow multiple function calls  
> inside a single
> XRPC-exchange. We could define a number of modes of execution, most  
> notably:
> - snapshot (in the same snapshot, sharing XML fragments). We could  
> even allow a
> special notation to use the result of one function as a parameter to  
> next
> function (assuming identical number of iterations). This allows some  
> more
> decompositions and allows us to do distributed code motion on the  
> result of a
> function.
> - sequential (next call sees results of the previous). Here we would  
> just
> sequentially execute a number of queries. That is the one Maurice  
> wants.

I would vote for the multiple function calls solution.  With the  
'sequential' one, we can already solve the problem that we cannot  
decompose subqueries in a sequence construction in some cases.


> Peter
>> -----Original Message-----
>> From: Keulen, M. van (Maurice) [mailto:m.vankeulen at utwente.nl]
>> Sent: Friday, March 28, 2008 12:40 PM
>> To: P.Boncz at cwi.nl
>> Cc: 'Ying Zhang'; monetdb-developers at lists.sourceforge.net
>> Subject: Re: Monetdb-developers Digest, Vol 22, Issue 4
>> Peter Boncz wrote:
>>> Hi Maurice,
>>> That is not possible.. without adding extensions such as
>> proposed in XQueryP or
>>> XQuery-Bang.
>>> Why is it that running the update followed by a query is
>> not acceptable?
>> Running an update followed by a query is acceptable. My point is that
>> the update and the query are both "requests" ...
>> *asynchronous* requests
>> if you use XRPC as communication mechanism. I don't mind sending the
>> update and the query in separated requests, but it seems to me
>> inefficient and cumbersome for a developer that he needs to
>> program it
>> in such a way that he sends the update, necessarily waits for
>> it to be
>> completed, then sends the query and waits for the result. The
>> developer
>> is not interested in the response to the update. Hence, it
>> would be IMO
>> better if this developer can simply send the update, and
>> without waiting
>> for it to be completed, send the query and wait for the result of the
>> query. In this way, he assumes however that the query 'sees'
>> the result
>> of the update ... and I am not convinced that this is what he
>> will get,
>> because: it is not guaranteed that the update request is
>> received by the
>> server before the query request, and that the update request
>> is finished
>> before the query request starts. Like I said, I'm only mimicking an
>> application sending "UPDATE;SELECT" to a relational database.
>>> Another idea is to use fn:put() in the update, and then
>> just a HTTP GET to get
>>> the XML result out. That is still a single query.
>> Why is this a single query? I need to send one XRPC message
>> that calls a
>> function in a module that does the fn:put(), and another request with
>> HTTP GET to get the result out ... and the application has to
>> wait for
>> the response of the XRPC message, before doing the HTTP GET, right?
>> We are now discussing full-fledged transactions and what I
>> would expect
>> from MXQ if it would support full-fledged transactions. My original
>> question was much simpler. I want the result of a query to be both
>> stored and sent back to the application. This requires 2
>> requests that
>> need to be executed serially: fn:put(query,"doc.xml") ;  
>> doc("doc.xml")
>> Wouldn't it be very helpful, whatever restrictions or visibility
>> constraints, if this simple thing could be done in one
>> function, hence
>> one XRPC-request? I don't see any technical objections to allow the
>> XQuery expression below (i.e., remove the typing constraints) and say
>> that the semantics is that it results in (1) an update tape applied
>> afterwards, and (2) a query result (everything in the
>> sequence that is
>> not an update), and hence that updates done in a query are
>> not visible
>> to the query itself.
>> let $answer := query
>> return (fn:put($answer,"doc"), $answer)
>> This would already make live much easier for a developer in
>> many simple
>> cases.
>> 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

More information about the developers-list mailing list