Bug #6217
closedSliding windows: finished windows not output if windows that started earlier are unfinished
0%
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?
Updated by Michael Kay about 1 year ago
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.
Updated by Christian Grün about 1 year ago
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)
Updated by Christian Grün about 1 year ago
…thanks for your feedback; good to know that our expectations are in line.
Updated by Michael Kay about 1 year ago
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...".
Updated by Michael Kay about 1 year ago
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.
Updated by Michael Kay about 1 year ago
- 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.
Updated by Michael Kay about 1 year ago
I've created push/pull variants of some of the existing tests.
Updated by Michael Kay about 1 year ago
- 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.
Updated by O'Neil Delpratt about 1 year ago
- 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