Bugs item #2668437, was opened at 2009-03-06 15:30
Message generated for change (Comment added) made by stmane
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2668437&group_id=56967
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: PF/runtime
Group: Pathfinder "stable"
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Jan Rittinger (tsheyar)
Assigned to: Peter Boncz (boncz)
Summary: PF runtime: parent step produces not/wrongly sorted result
Initial Comment:
The following query returns the wrong number:
count(doc("consumer04.xml")//properties/../properties)
The reason is the parent step implementation (loop_lifted_parent_step) that
makes some assumptions that are not true (see following example).
If I run the following query with debug mask 10 I get a warning:
> echo 'count(doc("consumer04.xml")//properties/..)' | pf | Mserver --debug=10
#BATpropcheck: BAT tmpr_2464(-1332)[oid,oid] with 1156921 tuples was
incorrectly marked sorted!
#BATpropcheck: BAT tmpr_2464(-1332)[oid,oid] with 1156921 tuples remains marked
radix-clustered on 32 bits; not checked!
<?xml version="1.0" encoding="utf-8"?>
<XQueryResult>1156921</XQueryResult>
The document consumer04.xml is linked in the XIRAF testset in the pathfinder
wiki.
----------------------------------------------------------------------
>Comment By: Stefan Manegold (stmane)
Date: 2009-03-19 20:20
Message:
With only 1 iter, the item's/pre's in the result should be sorted,
but they are apparently not.
Not setting the sortedness property seems to avoid
the reported property error
without harming any (other) Pathfinder/XQuery tests;
and seems to make all Xiraf test queries work.
Hence, I disable setting the tail-sorted property
of the ll_upwards results in the Feb2009 release branch,
but prevent propagation to the development trunk,
as I am not convinced that this is the proper fix.
Rather, we should check, why the result is not sorted
as we expect it to be ...
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2009-03-17 12:47
Message:
Added test in
pathfinder/tests/BugTracker/Tests/parent_wrong_properties.SF-2668437.*
Fails with property error as reported.
When the sortedness property is not set
(i.e., removing "bn->tsorted = GDK_SORTED"
from pathfinder/runtime/ll_upwards.mx),
it seems to work fine --- at least there is
not property error any more --- the result
still need to be checked/verified.
However, I'm not sure whether not setting
the sortedness property is the correct solution,
since I still expect ll_parent to produce a result
with the tail values (pre/item) sorted per iter,
i.e., globally sorted with only one iter.
----------------------------------------------------------------------
Comment By: Maurice van Keulen (mvankeulen)
Date: 2009-03-17 09:53
Message:
You're right. I keep being amazed about some parts of the language design.
I understand the logic behind it, but for me, it is quite counter-intuitive
that preceding::foo[1] and (preceding::foo)[1] count the foo-elements in
opposing directions.
----------------------------------------------------------------------
Comment By: Jan Rittinger (tsheyar)
Date: 2009-03-17 09:42
Message:
Maurice, you are wrong here---all steps are supposed to return their result
in document order.
Reverse document order only plays a role in positional predicates, please
read http://www.w3.org/TR/xquery/#dt-predicate.
----------------------------------------------------------------------
Comment By: Maurice van Keulen (mvankeulen)
Date: 2009-03-17 09:26
Message:
Just to be sure, backward axes need to produce their results in REVERSE
document order. So I expect the result of PFll_parent to be first ordered
on iter and then descending on pre.
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2009-03-12 19:13
Message:
I assume, that it is not the properties that are set incorrectly --- the
result of PFll_parent is supposed to be ordered on [iter,pre], i.e., with
only one iter this also means that it is sorted in pre --- hence, I suspect
that either the ll_upwards implementation itself is wrong in this case,
since is produces an obviously not sorted pre column, or is is working on
inconsistent data/input due to a previous bug elsewhere, and hence, works
incorrectly ...
... also getting Peter as original author of the ll_upwards code involved
...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2668437&group_id=56967
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
