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/
Hi all, In order to have a "dynamic backend” implementation to REST-XQ invocations we used the fn:function-lookup() function but we are experiencing a strange behavior if the target looked-up function is an updating function that for example adds a resource to a database.
Putting the provided files in the webapp folder of a fresh new BaseX latest (9.3.2) downloaded instance (adding "MIXUPDATES = true” setting in the .basex and with a database named DB already created inside) and invoking the REST function that calls directly the backend function with [1] the resource is correctly created on the database, by invoking the REST function that performs the dynamic lookup by using the fn:function-lookup() with [2] it completes without errors but the resource is not added to the DB. In our implementation the implementation modules are stored in the repo but the same behavior can be reproduced with “direct” function call as per my example.
Is there any limitation in the looked-up function related to updating databases?
Regards,
Mauro
[1] http:send-request( <http:request method="POST"> <http:body media-type="application/xml"/> </http:request>, "http://localhost:8984/store",
<joe/> ) [2] http:send-request( <http:request method="POST"> <http:body media-type="application/xml"/> </http:request>, "http://localhost:8984/dyn-store", <joe/> )