Hi Christian,

Although the string evaluated by xquery:eval will always be an XPath, that string is itself constructed within a rather complex query. The query accepts several parameters which are each used to construct individual XPath expressions. Originally the query was constructed so that each of these XPaths were evaluated immediately, by applying them to a common subset. This subset would then successively narrow as each parameter was applied. However, I realised that by constructing the complete XPath and applying it once through xquery:eval I could better leverage the optimisation of BaseX. This approach improved performance dramatically.

It sounds like what I'm trying to do isn't possible currently, but I'd certainly appreciate it if it could be made possible in an update.

Many thanks

Marc

M. Balston

M: +44 7786 263 906

On Monday, 8 August 2022 at 15:49:38 BST, Christian Grün <christian.gruen@gmail.com> wrote:

Hi Marc,

The invocation of xquery:eval requires admin privilegues; but if you
are an admin user, you can decide under which permissions this query
will be executed.

If you want to evaluate an XPath expression with a limited user and
the REST API, it should be sufficient to supply this path as query:

http://localhost/rest/db?query=/path

You can also address and run a server-side query:

http://localhost/rest/db?run=xpath.xq

If you need to further process the results of a dynamic XPath query,
you’ll probably need to switch to RESTXQ.

Your use case is inspiring, though: Maybe we could make xquery:eval
more flexible and run it with the permissions of the current client. A
client may then be allowed to further restrict the permission scope:
If a client has 'read' permissions, (s)he could further restrict the
permissions to 'none' (but not extend it to e.g. 'write').

I’ll have some more thought on that, as we currently don’t have any
functions that have dynamic permissions at runtime.

Best,
Christian