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

Peter Boncz P.Boncz at cwi.nl
Fri Mar 28 14:01:43 CET 2008


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).

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.

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