Thanks for the explanation.

Wanting to parameterise the input collections, in fairly simple ways, seems to me a natural and common requirement.

but the consequence of a global read lock is all other tasks are unable to access any database. So great care required ;-)

>Variables will only be inlined at compile time, i.e., after the locks have already been assigned.

Consider a function:

bxcode:inline-variables($xqcode-uri) as xs:string

@returns xquery code that is the source code from $xqcode-uri but with inlining "constant" variables and operations applied

This could be used as a preprocessor.

Is this something that could be created from the bits and pieces in the current BaseX Java code?

/Andy

On 20 September 2017 at 18:27, Christian Grün <christian.gruen@gmail.com> wrote:

Hi Andy,

> Note @reads="BEP"
>
> Is this correct and/or of any consequence?

This is correct: If the argument of fn:collection, fn:doc, etc. is
directly supplied as string argument, it is possible to statically
detect (at parse time) which database needs to be locked. Variables
will only be inlined at compile time, i.e., after the locks have
already been assigned. As a result, your first query will cause a
global lock.

Currently, we only have one compilation step. In an ideal BaseX world,
we would have at least 2 steps:

1. Static compilation, in which a query would be typed and rewritten
without considering dynamic input (external variables, databases, …).
The result could be reused several times, and in your case, the
database name would have been inlined.

2. Dynamic compilation, which binds external variables (from clients,
RESTXQ calls, etc.), checks databases for index structures, etc.

It might turn out that Step 1 is too expensive in order to be
evaluated before locking a query. On the other hand, static
compilation needs not be locked, it can always run in parallel with
queries that are currently evaluated.

Does this answer your question?
Christian