Hi Lee Thanks for the clarification.
Thanks & regards, Ravinder Singh Maan On Mon, Jun 22, 2015 at 12:20 AM, <[email protected]> wrote: > Send General mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://developer.marklogic.com/mailman/listinfo/general > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of General digest..." > > > Today's Topics: > > 1. Re: Is Content-Encoding: gzip supported? (Florent Georges) > 2. Re: Search and update -- Correction (David Lee) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 21 Jun 2015 21:21:16 +0200 > From: Florent Georges <[email protected]> > Subject: Re: [MarkLogic Dev General] Is Content-Encoding: gzip > supported? > To: MarkLogic Developer Discussion <[email protected]> > Message-ID: > <CADyR_r292qtVJ1mLqO0R1L+S=4G06dWs7WUon= > [email protected]> > Content-Type: text/plain; charset=UTF-8 > > Thank you, Geert, I did not know we had a gunzip function, good to know! > > So it seems the HTTP client does not honour the Content-Encoding. > Should I open a ticket, or did I miss something? > > Regards, > > -- > Florent Georges > http://fgeorges.org/ > http://h2oconsulting.be/ > > > On 19 June 2015 at 20:02, Geert Josten wrote: > > Try this instead: > > > > var url = "http://api.stackexchange.com/2.2/";; > > xdmp.gunzip(fn.subsequence(xdmp.httpGet(url, { format: 'binary' }), 2, > 1), > > { format: 'json'}); > > > > > > Cheers > > > > On 6/19/15, 7:20 PM, "Florent Georges" <[email protected]> wrote: > > > >> Hi, > >> > >> The following query: > >> > >> var url = "http://api.stackexchange.com/2.2/";; > >> xdmp.httpGet(url); > >> > >>throws the error: > >> > >> XDMP-JSONDOC: [...] -- Document is not JSON > >> > >> Is it possible this is related to the API always returning > >>GZIP-encoded content? It can return DEFLATE-encoded content as well, > >>but the problem remains the same when passing Accept-Encoding: > >>DEFLATE. > >> > >> If trying to get the result with format: "text", the error is > >>"document is not UTF-8 encoded", which is true if the GZIP encoding is > >>not taken into account. > >> > >> Regards, > >> > >>-- > >>Florent Georges > >>http://fgeorges.org/ > >>http://h2oconsulting.be/ > >>_______________________________________________ > >>General mailing list > >>[email protected] > >>Manage your subscription at: > >>http://developer.marklogic.com/mailman/listinfo/general > > > > _______________________________________________ > > General mailing list > > [email protected] > > Manage your subscription at: > > http://developer.marklogic.com/mailman/listinfo/general > > > ------------------------------ > > Message: 2 > Date: Sun, 21 Jun 2015 23:20:33 +0000 > From: David Lee <[email protected]> > Subject: Re: [MarkLogic Dev General] Search and update -- Correction > To: 'MarkLogic Developer Discussion' <[email protected]> > Message-ID: > < > 6ad72d76c2d6f04d8be471b70d4b991e0bcd6...@exchg10-be01.marklogic.com> > Content-Type: text/plain; charset="utf-8" > > Correction on #2) " Xdmp:node-insert and similar operate in-memory only" > I was thinking of a different api, the 'in memory' update > > https://github.com/marklogic/commons/blob/master/memupdate/in-mem-update.xqy > > The xdmp:node-insert* functions do operative directly on the document 'on > disk' > Internally they perform the equivalent of a complete read/delete/write of > the entire document each call - multiple calls in the same transaction > should be avoided vs reading the document in memory, modifying it and > writing it out as one operation ( exceptions in cases of very large > documents may be a wash) > > I fell victim to the exact confusion mentioned by "jimuller2002" aka > "anonymous" right there in doc comments - "RTFM" I should have :) > > https://docs.marklogic.com/xdmp:node-insert-child > > " A common issue I've seen with developers updating nodes is not > understanding the difference between updating a node in a document, in the > database ... versus updating a node in a document that is in memory." > > In my case its not 'not understand' but rather 'not remembering' which API > does what -- the result equally confusing. > > > > > > ----------------------------------------------------------------------------- > David Lee > Lead Engineer > MarkLogic Corporation > [email protected] > Phone: +1 812-482-5224 > Cell: +1 812-630-7622 > www.marklogic.com<http://www.marklogic.com/> > > From: David Lee > Sent: Sunday, June 21, 2015 9:59 AM > To: MarkLogic Developer Discussion > Subject: RE: [MarkLogic Dev General] Search and update > > > 1) See #3 > > 2) Xdmp:node-insert and similar operate in-memory only, so themselves > do not cause lock problems because they don?t write the document. See #3 > > 3) Yes, to split up an XQuery program into separate transactions to > avoid locking issues, > you can use one of the xdmp:eval* or xdmp:invoke* functions. > I encourage you to look at xdmp:invoke-function() as it doesn?t require a > separately stored module (like xdmp:invoke) and it doesn?t have issues with > escaping XQuery as strings and the associated risks > of XQuery injection (by mistake or intent). > Note: it?s not sufficient to run the update portion in a separate > transaction if you have already run the query/search > in the main transaction ? the read locks are already acquired, and running > an update as a synchronous child transaction will block attempting to write > to the same document searched (depending on the details of the query and > update) > Like this > [ Main Transaction ] > Results = Query --> Creates Read Locks > Apply [ Update -> Waits on Read Locks ] --> Potential deadlock > [ END Main transaction ] > > > To avoid this run *both* search and query as child transactions of an > ?auto? transaction. > > Like this > [ Main transaction ] > Results = [ Query Transaction ? Creates Read Locks ? Query ? End > Transaction Releases Locks ] > Apply [ Update Transaction ? Creates Write lock on 1 doc ? no blocking > - Release Lock ] > [ END ] > > This way the Query transaction has completed and released its locks before > running the update. > The above example could run the Apply in the parent Transaction ? but only > very carefully, > If the Apply uses an update method that the XQuery parser can detect on > parsing it may upgrade the auto > Transaction to a Update transaction before the query occurs. > > Note also that this is no longer an atomic operation ? If your logic > requires that the Update is synchronized, > ( 2 parallel requests updating based on ?stale? information ) > you may need to an additional check in the update to make sure the > document being updated > has not changed since the query ? This won?t cause any locking problems if > you make the check and update > In the same transaction *for a single document* - > > Take a look at xdmp:invoke-function() for examples ? XQuery 3.0 anonymous > functions are really handy for this. > > > > From: [email protected]<mailto: > [email protected]> [mailto: > [email protected]] On Behalf Of RAVINDER MAAN > Sent: Sunday, June 21, 2015 6:21 AM > To: [email protected]<mailto:[email protected] > > > Subject: [MarkLogic Dev General] Search and update > > Hi all > > I have a update job which search for documents matching criteria and then > insert or delete a node in the matching docs. I know that if search and > update is in same transaction it causes lock problems. So search return URI > of the docs and in second request I do fn:doc and node insert or replace. > Which seems to be working. I have below questions > > 1. How other people are handling search and update ? Is there any other > way? > 2. Does the XPATH search and replace also cause locking problem? for > example xdmp:node-replace(/root/old-node, $new-node) > 3. Is it good idea to perform search and do the update in xdmp:eval with > different-transaction ? > > > Thanks & regards, > Ravi > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://developer.marklogic.com/pipermail/general/attachments/20150621/663fe99f/attachment.html > > ------------------------------ > > _______________________________________________ > General mailing list > [email protected] > Manage your subscription at: > http://developer.marklogic.com/mailman/listinfo/general > > > End of General Digest, Vol 132, Issue 42 > **************************************** >
_______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
