The erroneous index rewriting has been resolved (it only occurred if
downward and upward attribute axes were mixed) [1]. A new snapshot is
available [2].
Cheers,
Christian
[1] https://github.com/BaseXdb/basex/issues/1490
[2] http://files.basex.org/releases/latest/
On Sun, Aug 20, 2017 at 5:17 P
Hi Nikos,
I had a look at the optimized query plans. Apparently, one of the
index rewriting rules composes the inversed path in a wrong way:
db:open('bug')//@a/..[@* = "x"]
…is rewritten to…
db:attribute("bug", "x")/..[a/..]
…while it should be…
db:attribute("bug", "x")/..[@a/..]
…or (
On 20.08.2017 15:29, nikos dimitrakas wrote:
I discovered a strange behavior i BaseX (8.6.5):
But when I evaluate
//S/@k/parent::*[.//@m="V"]
or
//S/@k/..[.//@m="V"]
it does not work. There is no error, just no result.
When I run your path expression directly against your posted sample with
Hi!
I discovered a strange behavior i BaseX (8.6.5):
I evaluate
//S/@k/parent::*
or
//S/@k/..
and it works
I evaluate
//S[.//@m="V"]
and it works
But when I evaluate
//S/@k/parent::*[.//@m="V"]
or
//S/@k/..[.//@m="V"]
it does not work. There is no error, just no result.
At first I thought that the
4 matches
Mail list logo