Thanks for fixing it—glad to know it wasn’t just me
😊
Cheers,
E.
_____________________________________________
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
LinkedIn | Twitter | YouTube | Facebook
From:
Christian Grün <christian.gruen@gmail.com>
Date: Monday, February 28, 2022 at 9:24 AM
To: Eliot Kimber <eliot.kimber@servicenow.com>
Cc: basex-talk@mailman.uni-konstanz.de <basex-talk@mailman.uni-konstanz.de>
Subject: Re: [basex-talk] CREATEFILTER Setting Not Being Applied
[External Email]
Hi Eliot,
I was surprised to see your observation leading me back to an adjustment made in 2014. Back then, global parsing options erroneously influenced the behavior of fn:doc. The global
value of the CREATEFILTER, among others, is now considered when using db:create. See [1] for the whole picture and [2] for a new snapshot.
Cheers,
Christian
On Sat, Feb 26, 2022 at 3:05 PM Eliot Kimber <eliot.kimber@servicenow.com> wrote:
In my basex/.basex file I have this local option:
# Local Options
CREATEFILTER=*.xml,*.dita,*.ditamap
I have three BaseX instances running.
And in the DBA panel for an instance not running on the default port (i.e., on port 10894) I see this in the Local Options column:
CREATEFILTER
*.xml,*.dita,*.ditamap
SKIPCORRUPT
✓
However, if I do this from the Query console of that same server:
db:create(‘mydatabase’, ‘/path/to/docs’)
The resulting database only reflects .xml files, not .dita or .ditamap files.
I’m wondering if this is a bug in how CREATEFILTER is being applied or my misunderstanding of the implications for CREATEFILTER?
This is running 9.6.4 on Centos.
If I specify createfilter directly on the db:create() call then of course it works as expected.
Cheers,
E.
_____________________________________________
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368