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:
- 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.
- 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