Fair enough, I tried with the latest version and I don't get an error. 

I'm not sure what happened with the double update though. 

On Mon, Nov 10, 2014 at 3:12 PM, Christian Grün <christian.gruen@gmail.com> wrote:
Hi France,

>    1) A process runs that tries to update the same .xml file twice within a
> single updating function. Or a writer may save a file or import a file from

Maybe we should disallow this, because it's also not allowed to
replace the same node in a database more than once. I will think about
it.

> Here is a small test function to replicate the scenario.

Thanks for the RESTXQ code. This is what I tried:

* I created a new, empty database named 'en-us'
* I started the BaseX HTTP server with your RESTXQ function
* I called the URL "localhost:8984/tests/tries2"
* I changed $x !='C' to $x ='C'
* I called the URL again
* I got 200 as result

What do I need to change in order to trigger the error? I noticed that
the example does not contains any call to db:store, which would create
a raw file.

I hate to say it, but… If I did everything right, could you once more
check the latest snapshot? I remember that we refactored the
replace/add/store code in September. Maybe the issue has been fixed
during those rewritings?

Sorry for the circumstances,
Christian
___________________________________

On Mon, Nov 10, 2014 at 9:26 PM, France Baril
<france.baril@architextus.com> wrote:
> Hi,
>
> For many reasons, we often encounter this pattern:
>
>    1) A process runs that tries to update the same .xml file twice within a
> single updating function. Or a writer may save a file or import a file from
> translation that is not well formed.
>      Result: the .xml file is now saved as a raw file.
>    2) A second process (or the same process) tries to update that file
> again.
>      Result: Improper user? Potential big? issue.
>
> Because we can't seem to catch the error on the 1st run (or maybe I'm trying
> the wrong way?), we might carry for a while without knowing that an issue
> occured. Then we get the second message, which is not very helpful because
> it doesn't help us catch the issue that caused the error.
>
> Would it be possible to improve the error handling on this issue, mostly to
> catch it on step 1?
>
> Here is a small test function to replicate the scenario.
>
>  First call it with $x !='C'
>  Then, change the test condition to $x = 'C' and call it again for the
> improper use   error.
>
> declare %rest:path('tests/tries2')
>    %rest:GET
>    %output:method('html')
>    %output:html-version('5.0')
> updating function tries:controller2(){
>   try {
>       for $x in ('A', 'B', 'C')
>       return if ($x != 'C')
>              then db:replace('en-us', 'test-updates.xml', <div>Hi!</div>)
>              else ()
>   } catch * {
>
>     (: This does not catch the issue in db:replace for a double update on
> the same file :)
>      db:replace('en-us', 'errors.xml',
>      <div style="color:red;">
>         <h1>Error</h1>
>         <p>{$err:code}: {$err:description}</p>
>         <div>{$err:value}</div>
>      </div>)
>   }
> };
>
>
> Regards,
>
>
> France
>
> --
> France Baril
> Architecte documentaire / Documentation architect
> france.baril@architextus.com



--
France Baril
Architecte documentaire / Documentation architect
france.baril@architextus.com