I wasn't suggesting hard coding the content-specfic bits. I was suggesting passing XQuery as a restful param to allow any XQuery to update /documents. A bit like passing it over XCC. Making the endpoint total generic. Not totally RESTful but still pragmatic.
I will take a look at extensions as I can see this is against MarkLogics RESTful philosophy Cheers Jem -----Original Message----- From: [email protected] on behalf of Michael Blakeley Sent: Mon 19/11/2012 5:11 PM To: MarkLogic Developer Discussion Subject: Re: [MarkLogic Dev General] Marklogic REST API. [Multi-statement tx] So the objection is that content-specific bits, such as the timestamp check, would have to be hard-coded? There is a generic version of conditional updates in the REST API. It relies on ETag, as described at http://docs.marklogic.com/guide/rest-dev/documents > When content versioning is enabled, MarkLogic Server associates an opaque > version id with a document. The version id changes each time you update the > document through your REST API instance. The version id is returned in the > ETag header when you read a document, and you can pass it back in an If-Match > header during an update or delete operation to test for changes prior to > commit. Granted that isn't quite the same as a timestamp check. But you could build your own mechanism with a similar level of generic functionality. You could parameterize your timestamp check so that it can use any relative XPath compatible with xdmp:unpath. The code might look something like this: ... declare variable $OLD := doc($URI) ; if (empty(doc($URI)) or $TIMECODE lt ($OLD ! xdmp:unpath($PATH))) then () else xdmp:document-insert( $URI, xdmp:unquote($XML), xdmp:default-permissions(), local:getCollections()) Except for $OLD, all the capitalized variables would come from the $params map. Now there is nothing content-specific about the code, and you can use it with any content that has a timestamp at some known path. If you cannot trust the caller to set the PATH parameter correctly, create a lookup table using arbitrary codes. Use the caller-supplied code to look up the correct path, or throw an error if it is invalid. The code for that would be a little longer, but should still perform well. -- Mike On 19 Nov 2012, at 08:51 , Jem Rayfield <[email protected]> wrote: > Extending the REST API every time you want to do constraint controlled > Document Create, Update, Deletes seems like a fair amount of extra work. > If this is the approach then I guess I can look at it. > > I was just thinking that perhaps something along the lines of would be > availible: > > /documents&query=XQuery&bind:x=X&bind:y=Y > > Update /documents using the adhoc XQuery with a set of variable bindings. > Where these bindings could be the XML for the doc and params. > > I guess I need to look at extensions. > > Thanks for the pointer re fn:exists(). > > > > -----Original Message----- > From: [email protected] on behalf of Michael Blakeley > Sent: Mon 19/11/2012 4:41 PM > To: MarkLogic Developer Discussion > Subject: Re: [MarkLogic Dev General] Marklogic REST API. [Multi-statement tx] > > Jem, why not extend the REST API to implement that as a single request? That > should give you the benefits of using the REST API, without requiring > multiple requests. > > http://docs.marklogic.com/guide/rest-dev/extensions discusses this feature > and has an example that you could modify to suit your application. > > BTW in your sample code below I would probably use fn:exists() rather than > xdmp:exists(). You are using that boolean to decide whether or not to update > the database. Therefore you probably want ACID consistency guarantees, which > xdmp:exists explicitly avoids in its subexpression because it always runs > timestamped. Replacing it with fn:exists(doc($documentUri)) will read-lock > any document at $documentUri, which guarantees consistency and avoids a > potential race condition. > > -- Mike > > On 19 Nov 2012, at 07:59 , Jem Rayfield <[email protected]> wrote: > > > Hi, > > > > Would I be correct that the following type of XQuery should be translated > > to a sequence of REST calls using a tx-id. > > So, a single simple XQuery update such as: > > > > if (xdmp:exists(doc($documentUri))) > > then ( > > if ($timeCode < xs:dateTime(doc($documentUri)/document/header/timeStamp) ) > > then () > > else ( > > xdmp:document-insert($documentUri, xdmp:unquote($xml), > > xdmp:default-permissions(), local:getCollections()) > > ) > > )else ( > > xdmp:document-insert($documentUri, xdmp:unquote($xml), > > xdmp:default-permissions(), local:getCollections()) > > ) > > > > Would be translated to a number of REST calls: > > > > Get a transaction; /transactions > > Invoke XQuery to get time stamp using the tx id; /query > > Update Document using the tx id; /documents > > > > Or is there a better way of doing this using the current REST API spec? > > There could be a lot of I/O etc for something quite simple. > > > > I may have missed something here so please do point me in the right > > direction. > > > > Cheers > > Jem > > > > > > > > http://www.bbc.co.uk > > This e-mail (and any attachments) is confidential and may contain personal > > views which are not the views of the BBC unless specifically stated. > > If you have received it in error, please delete it from your system. > > Do not use, copy or disclose the information in any way nor act in reliance > > on it and notify the sender immediately. > > Please note that the BBC monitors e-mails sent or received. > > Further communication will signify your consent to this. > > _______________________________________________ > > General mailing list > > [email protected] > > http://developer.marklogic.com/mailman/listinfo/general > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > > > > > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and may contain personal > views which are not the views of the BBC unless specifically stated. > If you have received it in error, please delete it from your system. > Do not use, copy or disclose the information in any way nor act in reliance > on it and notify the sender immediately. > Please note that the BBC monitors e-mails sent or received. > Further communication will signify your consent to this. > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
