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. Jennie > > > Peter > > > >> -----Original Message----- >> From: Keulen, M. van (Maurice) [mailto:[EMAIL PROTECTED] >> Sent: Friday, March 28, 2008 12:40 PM >> To: [EMAIL PROTECTED] >> Cc: 'Ying Zhang'; [email protected] >> 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: [EMAIL PROTECTED], Phone: +31 534893688, Fax: +31 >> 534892927 >> Room: ZI 3039, WWW: http://www.cs.utwente.nl/~keulen >> > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Monetdb-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-developers
