Yes, because the two evals are now two distinct, serialized
transactions, the first will always complete before the second.
Wayne.
On Mon, 2008-10-27 at 13:52 -0500, Strawn, Shane wrote:
> Thanks guys - I tried Wayne's way and it appears to be working. Since the
> inserts go into separate dbs, I didn't see any way to dispose of the eval, so
> I end up with:
>
> xdmp:eval('xdmp:document-insert( "process-me.xml", <data>...</data>)',
> different-transaction )
> ...
> xdmp:eval('xdmp:document-insert( "cpf-init.xml",
> <target-uri>process-me.xml</target-uri>)', different-database )
>
> So with this method will the sequence always be top down, completing the
> first eval before the second one?
>
> Thanks again,
> Shane
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Danny Sokolsky
> Sent: Monday, October 27, 2008 2:39 PM
> To: General Mark Logic Developer Discussion
> Subject: RE: [MarkLogic Dev General] (no subject)
>
> Another possibility is, if this code is in the body of a main module, you can
> separate them into separate transactions by putting a semi-colon after the
> first document-insert. This might also eliminate the need for the eval
> (depending on what else you are doing in the query). For example:
>
> xdmp:document-insert( "process-me.xml", <data>...</data>) ;
>
> xdmp:document-insert( "cpf-init.xml",
> <target-uri>process-me.xml</target-uri>)', $options (:
> setting db to content :) )
>
> -Danny
>
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Feick
> Sent: Monday, October 27, 2008 11:01 AM
> To: General Mark Logic Developer Discussion
> Subject: Re: [MarkLogic Dev General] (no subject)
>
> Have you considered inserting process-me.xml in a separate eval with an
> option of <isolation>different-transaction</isolation> to ensure it is
> available before when inserting cpf-init.xml?
>
> Wayne.
>
>
> On Mon, 2008-10-27 at 11:29 -0500, Strawn, Shane wrote:
>
> Hello,
>
> I have a somewhat convoluted issue to describe so I'll try to make sense:
>
> I have a Content Processing Framework process which watches a directory for a
> file to be dropped on it. This is a different database than my main content
> database.
>
> I have an xquery module which at the same time inserts a document into the
> content database, and the above file into the CPF database in an eval, like
> so:
>
> xdmp:document-insert( "process-me.xml", <data>...</data>)
> ...
> xdmp:eval('xdmp:document-insert( "cpf-init.xml",
> <target-uri>process-me.xml</target-uri>)', $options (:
> setting db to content :) )
>
> Now, since these are in different dbs, it sometimes occurs where the CPF
> process will look for "process-me.xml" on the content db but not find it,
> because it is not finished document-inserting. I thought it should complete
> the doc-insert before moving on to the eval in the module, but it apparently
> doesn't due to the separate-transaction nature of the situation?
>
> I would like to find a way to loop or wait until my doc is fully inserted
> within xquery, rather than the more complex tasks of modifying the CPF
> pipeline or changing the interface to add another click-through after the doc
> is inserted, if possible. But I'm not sure how to accomplish this or if it's
> realistic.
>
> I've tried some (probably) stupid things such as:
>
> Killing a set amount of time with a statement like
> let $timekill := for $a in (1 to 10000000) return () ...but this
> seems unreliable, and a waste of time if it doesn't need it;
>
> Or a recursive function like
> define function check-doc-exists($uri as xs:string) {
> if ( fn:exists(fn:doc($uri)) ) then fn:true() else
> check-doc-exists($uri) } ...but this gives me Stack Overflow within seconds,
> or if I put my timekiller in it, it never finds the doc even if it inserts
> while it is running.
>
> Is there something I can do here to create a loop which runs until it can
> find the document? Am I misunderstanding what is happening with the
> transaction? Just how wrong are my above ideas?
>
> Thanks in advance for any guidance.
>
> Shane Strawn
> Wolters Kluwer Health
>
> _______________________________________________
> General mailing list
> [email protected]
> http://xqzone.com/mailman/listinfo/general
> _______________________________________________
> General mailing list
> [email protected]
> http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
