Bugs item #2668437, was opened at 2009-03-06 15:30
Message generated for change (Comment added) made by tsheyar
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: Fixed
Priority: 9
Private: No
Submitted By: Jan Rittinger (tsheyar)
>Assigned to: Stefan Manegold (stmane)
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: Jan Rittinger (tsheyar)
Date: 2009-04-16 15:36
Message:
Peter, thanks for the explanation.
Re-assigning to Stefan to answer the question about the correct semantics
of the order flag. If the internal order is hidden correctly I'm confident
that the bug is fixed :)
----------------------------------------------------------------------
Comment By: Peter Boncz (boncz)
Date: 2009-04-16 14:39
Message:
sure, typo in the example (//b) you should have seen that:
e.g. <a x="1"><a x="2"><b x="3"/></a><b x="4"/></a>//b/../@x
has context sequence (<b x="3"/>,<b x="4"/>) and generates ("2","1")
ll_upwards always demands item input order.
- the anc and anc-or-self produce iter|item order
- parent never did that, it produces parents in the same order as the
input items, only with duplicates (in the same iter) eleminated. It wronly
assumed that if there was only one iter, the input item being sorted, the
output parents would also be sorted.
there is no contract that results are to be produced in a particular
order, IMHO.
I think this is fixed. Please close if you agree.
----------------------------------------------------------------------
Comment By: Jan Rittinger (tsheyar)
Date: 2009-04-16 14:24
Message:
Hi Peter,
I think I do not understand your example (as the result of your query is
'x="1"') and I do not understand the 'solution'.
Up till now the assumption was that calling loop_lifted_parent_step()
consumes the input in either iter|item or item|iter order and produces the
result in iter|item or item|iter order based on the order flag. Do you now
say that this assumption is false?
----------------------------------------------------------------------
Comment By: Peter Boncz (boncz)
Date: 2009-04-16 13:20
Message:
the algorithm produces parent nodes in the order of the context nodes.
it used to propagate ordering on the context into the result if the step
was not loop-lifted.
however, if the context sequence contains nodes from different depths,
this is simply incorrect.
e.g. <a x="1"><a x="2"><b x="3"/></a><b x="4"/></a>//a/../@x
has context sequence (<b x="3"/>,<b x="4"/>) and generates ("2","1")
----------------------------------------------------------------------
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
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
