Hello all,
we have probably found a bug, the cause of which is currently unclear to us.
Fortunately, the problem is reproducible in a small test case.
Steps to reproduce the problem:
1. import the following XML into a BaseX database "testcase".
### schnipp
<attributes foo="bar">
<attribute name="test1" seq="foo"/>
<attribute name="test2"/>
<attribute name="test3" seq="bar"/>
</attributes>
### schnapp
2. make sure that an attribute index has been created.
3. execute the following script.
### schnipp let $source := db:attribute('testcase', 'bar', 'foo')/..
let $value := (
$source/attribute[@name="test1"]/@seq/data(),
$source/attribute[@name="test2"]/@seq/data(),
$source/attribute[@name="test3"]/@seq/data()
)
return (
$value[2] => inspect:type()
) ### schnapp
Explanation:
The example is really only meant as a test case. For our case we have already found a workaround, so we don't have a serious problem.
The important thing is that the element is read from the database via db:attribute() and then the individual values are combined again into a sequence.
In doing so, we get an untypedAtomic from attribute test1, an empty-sequence() for test2 and an untypedAtomic again for test3.
Observation:
When we read the second value of the sequence by index ($value[2]), we get back an "attribute()" instead of an untypedAtomic.
Expectation:
We would expect an untypedAtomic here again.
Workaround:
We simply used string() instead of data() to explicitly cast the value to a string.
Versions:
We were able to reproduce the problem with 10.4 and the current 10.6. With a very old version 7.9, however, it was not reproducible.
Many thanks and best regards Andreas
Hi Andreas,
Thanks for the reproducible test case; a new snapshot with the bug fix is available [1,2].
Have fun, Christian
[1] https://files.basex.org/releases/latest/ [2] https://github.com/BaseXdb/basex/commit/2990c9eed30d4a98b74c2f1b36cf06940d5e...
On Tue, Jul 4, 2023 at 10:16 AM Andreas Hengsbach | nexoma andreas.hengsbach@nexoma.de wrote:
Hello all,
we have probably found a bug, the cause of which is currently unclear to us. Fortunately, the problem is reproducible in a small test case.
Steps to reproduce the problem:
- import the following XML into a BaseX database "testcase".
### schnipp
<attributes foo="bar">
<attribute name="test1" seq="foo"/>
<attribute name="test2"/>
<attribute name="test3" seq="bar"/>
</attributes>
### schnapp
make sure that an attribute index has been created.
execute the following script.
### schnipp let $source := db:attribute('testcase', 'bar', 'foo')/..
let $value := (
$source/attribute[@name="test1"]/@seq/data(),
$source/attribute[@name="test2"]/@seq/data(),
$source/attribute[@name="test3"]/@seq/data()
)
return (
$value[2] => inspect:type()
) ### schnapp
Explanation:
The example is really only meant as a test case. For our case we have already found a workaround, so we don't have a serious problem.
The important thing is that the element is read from the database via db:attribute() and then the individual values are combined again into a sequence.
In doing so, we get an untypedAtomic from attribute test1, an empty-sequence() for test2 and an untypedAtomic again for test3.
Observation:
When we read the second value of the sequence by index ($value[2]), we get back an "attribute()" instead of an untypedAtomic.
Expectation:
We would expect an untypedAtomic here again.
Workaround:
We simply used string() instead of data() to explicitly cast the value to a string.
Versions:
We were able to reproduce the problem with 10.4 and the current 10.6. With a very old version 7.9, however, it was not reproducible.
Many thanks and best regards Andreas
basex-talk@mailman.uni-konstanz.de