Graydon,
I implemented the “BaseX Orchestration” project for exactly this purpose: Enable doing operations that involve the creation or update of databases in series from a single driving script.
The project is here:
https://github.com/ekimbernow/basex-orchestration
It depends on the BaseX jobs facility. It also uses BaseX-specific unit testing features to enable useful unit testing of database create and update operations.
The code in GitHub is my initial take and I’ve refined my production code a bit (mostly to improve logging) and haven’t had bandwidth to back port it to the open source project, but I think the basic approach
is sound.
This is one of the key underpinnings of my Project Mirabel system, which I presented on at this year’s Balisage (https://balisage.net/Proceedings/vol27/html/Kimber01/BalisageVol27-Kimber01.html).
Cheers,
E.
_____________________________________________
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
LinkedIn | Twitter | YouTube | Facebook
From:
BaseX-Talk <basex-talk-bounces@mailman.uni-konstanz.de> on behalf of Graydon <graydonish@gmail.com>
Date: Sunday, November 27, 2022 at 11:15 AM
To: Christian Grün <christian.gruen@gmail.com>
Cc: BaseX <BaseX-Talk@mailman.uni-konstanz.de>
Subject: Re: [basex-talk] right way to create a db in the middle of processing?
[External Email]
On Sun, Nov 27, 2022 at 04:41:01PM +0100, Christian Grün scripsit:
> Hi Graydon,
Hi Christian,
[customary patient careful explanation of side-effect free language
design snipped]
I am sorry; I didn't even do a terrible job of explaining the use case,
because that was what my head was stuck in. Mea culpa!
What I want is something similar to transform() but for a main query
module, so I'm going to call it query(). I want this because I
frequently find myself using XQuery to test XML content sets, and
keeping the individual tests to an individual query module is much
simpler than trying to stuff everything into an eventually enormous set
of functions. But then they all have to be run individually and the
specific results aggregated together somehow to get the overall result.
It's possible to do this with the scripting functionality but I find
that gets hard to maintain and I'd really like an XQuery layer that
allows using multiple modules in a single at-least-notional query.
(The quality improvement I've experienced in XSLT from using transform()
and keeping every step of the transformation small and comprehensible
has been large; such an improvement may not generalize well, but if it
does, being able to treat a query module as a function seems highly
worthwhile for implementing anything complex in XQuery.)
I am not sure if my hypothetical query() function would be equivalent to
fn:load-xquery-module($module-uri as xs:string, $options as map(*)) as map(*)
from the 4.0 version of the functions spec at
https://www.saxonica.com/qt4specs/FO/Overview-diff.html#func-load-xquery-module
My idea would be
fn:query($module-uri as xs:string, $context as item()*, $options as
map(*)) as map(*)
where a db is explicitly available as a value for $context. (I realize
that document-node()* is not the type of a BaseX db, but given the
optimizer will substitute db:get() for collection() I figure it's
close...)
So it would be possible to do:
let $contentSet as xs:string :=
fn:query('load-set.xq', (), $options)?db-name
let $test1Result as map(*) :=
fn:query('test1.xq', $contentSet, $test-options)
let $test2Result as map(*) :=
fn:query('test2.xq', $contentSet, $test-options)
And so on.
I emphatically don't want to be able to update a DB and then query it
further in a single query module; I am sharply aware I'm not smart
enough not to mess that up!
Does that make any more sense?
Thanks!
--
Graydon Saunders | graydonish@gmail.com
Þæs oferéode, ðisses swá mæg.
-- Deor ("That passed, so may this.")