Bug #6217
closed
Sliding windows: finished windows not output if windows that started earlier are unfinished
Category:
XQuery conformance
Applies to branch:
11, 12, trunk
Fix Committed on Branch:
11, 12, trunk
Fixed in Maintenance Release:
Description
The following expression returns no results:
for sliding window $w in 1 to 3
start at $p when true()
only end when $p = 2
return element w { $w }
I would expect <w>1 2</w>
and <w>2</w>
as result, but Zorba returns <w>1 2</w>
, and all others I tried return an empty sequence. Did I get something wrong?
I think my expectation would be that the result should be <w>2</w>
. My reasoning: there are three candidate windows starting at positions 1, 2, and 3. These have $p=1, $p=2, and $p=3 respectively. For the first and third windows, the condition $p=2 is never true. For the second window, it is true for the first item in the window (in fact, the condition doesn't depend on which item you are looking at), so the window ends immediately.
I believe to remember that sliding windows were introduced by the Zorba guys, so I assumed their result may be correct, but I think they got it wrong: <w>1 2</w>
cannot be a correct result, as the position $p
is set to 1
for the complete first sliding window.
I now wonder if <w>2</w>
shouldn’t be returned for the second sliding window?
- Sliding Window 1:
1 2 3
- Sliding Window 2:
2 3
Here’s a slightly more complex query which doesn’t return <_ b='2'/><_ c='4'/><_ d='3'/>
as one might expect:
for sliding window $w in <x><_ a='1'/><_ b='2'/><_ c='4'/><_ d='3'/></x>/_
start $s next $n when $s/@* < $n/@*
only end $e previous $p when $e/@* < $p/@* and $p is $n
return ($s, $n, $e)
…thanks for your feedback; good to know that our expectations are in line.
Saxon is "despatching" a window with the content (2), but because windows have to be output in order of start position, and the window (1,2) is still open at that stage, the window (2) is put on a queue to be output when the disposition of (1,2) is known.
But the logic to empty the queue at the end is failing; the condition windowClause.isIncludeUnclosedWindows()
in WindowClausePush line 112 returns false, because of the keyword "end only when...".
Note that we have two versions of the logic, for use in push and pull mode respectively, and the same problem appears to be present in both.
- Subject changed from sliding windows to Sliding windows: finished windows not output if windows that started earlier are unfinished
- Assignee set to Michael Kay
Now fixed for push mode.
But pull mode is more difficult, there doesn't seem to be any end-of-input tidying up at all. I rather fear that most of the windowing test cases are being executed in push mode.
Update: no, it's not as bad as that, there's a fairly even split. But we certainly won't be getting complete coverage in either mode.
Result: 128 successes, 0 failures, 0 incorrect ErrorCode, 0 not run
COUNTERS
pull = 70
push = 39
Pull mode is being used for tests that have the "for window" expression at the top level, push mode for those that have it within an element constructor.
I've created push/pull variants of some of the existing tests.
- Category set to XQuery conformance
- Status changed from New to Resolved
- Applies to branch 11, 12, trunk added
- Fix Committed on Branch 11, 12, trunk added
- Platforms .NET, Java added
Now fixed.
Basically, both in pull and push mode, the code needs to check at the end of the input sequence whether there are any windows that have been finished, but that haven't been despatched because there are still windows with an earlier start position that haven't been finished and that don't auto-close at the end of the input.
- Fixed in Maintenance Release 12.4 added
Bug fix applied in the Saxon 12.4 Maintenance release. Leaving it marked as 'Resolved' until fix applied on Saxon 11.
Please register to edit this issue
Also available in: Atom
PDF