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@utwente.nl] Sent: Friday, March 28, 2008 12:40 PM To: P.Boncz@cwi.nl Cc: 'Ying Zhang'; monetdb-developers@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@utwente.nl, Phone: +31 534893688, Fax: +31 534892927 Room: ZI 3039, WWW: http://www.cs.utwente.nl/~keulen