I look forward to the longer term solution :)

But in the meantime these pragmas, although not pretty, would allow solutions to specific multitasking performance issues to be explored where currently they can be difficult/impossible. I think there is a certain elegance in advisory nature of pragmas.

>If manual locking is enabled, an error will be raised if a database is accessed that has not been specified in a lock pragma.

Is it required to specify all databases accessed within the manualock scope or could it work just specifying specific databases as readonly?

And the execution would error if these were violated.

/Andy

On Wed, 13 Feb 2019 at 16:56, Christian Grün <christian.gruen@gmail.com> wrote:

> Would this work where the database names are only known at run time?

Right now, our locking is based on static code analysis; runtime
information won’t be included. In the longer term, we would like to
extend our compiler to perform multiple steps:

1. Static parsing
2. Static optimizations (pre-evaluate 1+2 to 3, etc.)
3. Dynamic optimizations (reoptimize the query with query parameters
and other context information)
4. Physical optimizations (open databases, utilize available index structures)

Queries that have been parsed and statically compiled (Step 1+2) could
be stored as compiled queries, or kept in main-memory and duplicated
before dynamic optimizations take place. This could further reduce
access times in RESTXQ applications – and it would allow us to improve
locking, as we could do the lock check after Step 3.