Dear Christian,
About this problem we discover another issue that is causing us some troubles.
In the same scenario of calling RESTXQ updating functions discovered 
dynamically in a basex with MIXUPDATES turned on: if a reading function is 
called on the same DB while an updating function is storing some content in the 
DB the DB will be corrupted. We performed some tests and some times we get an 
OutOfMemoryError exception, some time an ArrayIndexOutOfBoundsException with 
the result that some “rubbish” data gets stored into the DB (e.g. standalone 
attributes).
I’ll provide you a SSCE [1] and the inserting function [2] we used to confirm 
the problem. During the save it is sufficient to call the read via rest several 
times with [3] to cause the problem. We tested on both last release (adding the 
“updating” prefix before the looked up function) and latest nightly build.

All my best,

    Mauro

[1] test.xqm file

module namespace _ = 'urn:test';

declare
  %rest:path("save")
  %output:method("json")
  %output:media-type('application/json')
  %rest:POST("{$resource}")
function _:create($resource as node()) {
  function-lookup(xs:QName("db:add"), 3)("test", $resource, random:uuid())
};

declare
  %rest:path("readall")
  %output:method("json")
  %output:media-type('application/json')
  %rest:GET
function _:readall() {
  <json type="object">{
    for tumbling window $in-window in function-lookup(xs:QName("db:open"), 
1)("test")
    start $first at $s when $s = 1
    end $last at $e when $e - $s = 10 - 1
    return $in-window
  }</json>
};

[2]
distinct-values(for $i in 1 to 10000
let $res := 
http:send-request(<http:request method="post">
      <http:body media-type="application/fhir+json"/>
    </http:request>, "http://localhost:8984/save";, '{
  "resourceType": "Encounter",
  "status" : "finished"
}')
return string($res[1]/@status))

[3] http://localhost:8984/readall

> Il giorno 31 mar 2020, alle ore 14:14, Christian Grün 
> <christian.gr...@gmail.com> ha scritto:
> 
> Dear Mauro,
> 
> The combination of higher-order functions and MIXUPDATE led to a wrong
> assignment of static properties of your updating expression. I have
> made the compilation step more rigid: If a dynamic function call is
> found, and if mixing updates is enabled, the function will now always
> be tagged as an updating function. Feel free to check out the latest
> stable snapshot [1].
> 
> If you want to stick with 9.3.2, you can prefix the function lookup
> call with an additional "updating" keyword:
> 
>  updating fn:function-lookup(fn:QName('urn:ns:impl2', 'store'), 1)($resource)
> 
> Cari saluti all’ Italia; our hearts are with you,
> Christian
> 
> [1] http://files.basex.org/releases/latest/

Reply via email to