Bugs item #2141012, was opened at 2008-10-01 22:13
Message generated for change (Comment added) made by sjoerd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2141012&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 general
Group: Pathfinder "stable"
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Loredana Afanasiev (lafanasi)
Assigned to: Jan Flokstra (jflokstra)
Summary: XQ: unclear error
Initial Comment:
Hi,
I have two identical in content collections, but one is read only the other is
updatable. I have two queries, which are identical with the exception of one
line that indicates the queried collection. Query 1 retrieves results, query 2
produces the error. I don't have any good guesses why..
[lafan...@zookst4 xq]$ diff tmp1.xq tmp2.xq
1c1
< let $col := fn:collection("MotiesTweedeKamer")
---
> let $col := fn:collection("MotiesTweedeKamer_Updatable")
[lafan...@zookst4 xq]$ mclient -lx -g tmp1.xq
<result count="1" year=""/>,
...
lafan...@zookst4 xq]$ mclient -lx -g tmp2.xq
MAPI = mone...@localhost:50000
QUERY = let $col := fn:collection("MotiesTweedeKamer_Updatable")
ERROR = !ERROR: err:FORG0003: function fn:zero-or-one expects at most one value.
cheers,
l.
----------------------------------------------------------------------
Comment By: Sjoerd Mullender (sjoerd)
Date: 2008-12-15 18:39
Message:
As discussed in the PF skype meeting, I tried fixing this bug in the stable
branch.
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-12-15 15:22
Message:
Jan F.,
once/if you fix this properly in the Nov2008 release branch, please recall
to also undo your preliminary fix the development trunk to avoid conflicts
during (semi-)automa[gnt]ic propagation.
Thanks!
Stefan
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-12-15 14:58
Message:
Jan F.,
thanks for the attempt to fix the problem.
The report should contain enough information to test whether the fix does
work.
Loredana, Lefteris,
assuming that you do have a setup ready where you can easily check Jan's
fix, could you please do so, too, and report here?
Thank you all in advance!
Stefan
----------------------------------------------------------------------
Comment By: Jan Flokstra (jflokstra)
Date: 2008-12-15 14:33
Message:
I tried to fix it in the shredder but I'm not shure if it fixes the
problem. The update code is pretty hairy and a lot of people having been
changing things since I last had a look at it. I now check before I start
shredding if the pre is in a hole and when this is the case I create a
proper hole and make the next pre the first pre after the new hole.Because
of the experimental character I checked it in in "Current". When I get
reports it fixes the problem I will properly do the fix in Stable,
JanF.
----------------------------------------------------------------------
Comment By: Jan Flokstra (jflokstra)
Date: 2008-12-15 14:33
Message:
I tried to fix it in the shredder but I'm not shure if it fixes the
problem. The update code is pretty hairy and a lot of people having been
changing things since I last had a look at it. I now check before I start
shredding if the pre is in a hole and when this is the case I create a
proper hole and make the next pre the first pre after the new hole.Because
of the experimental character I checked it in in "Current". When I get
reports it fixes the problem I will properly do the fix in Stable,
JanF.
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-12-12 18:20
Message:
After an exhaustive (and -ing) debugging session with combined forces of
Lefteris, Sjoerd and Stefan, we found that the problem is not in the
staircase join code, but rather in the shredder that seems to not properly
handle the (admittedly rare, but apparently not impossible) case that one
shredded document happens to end just before a hole on a page, and the next
(to be) shredded document hence begins on a new virgin page.
PRE table
#-------------------------------------------------------------------------------------------------------------------------#
# pre nid size level prop kind
tag cont # name
# void oid int chr oid str
str oid # type
#-------------------------------------------------------------------------------------------------------------------------#
...
Begin of document (15792th document in this case) that happens to end just
before the supposed hole starts:
[ 4176...@0, 3759...@0, 0, '\001', 0...@0, "TEXT",
nil, 1...@0 ]
[ 4176...@0, 3759...@0, 1893, 'ÿ', nil,
"DOCUMENT", nil, 1...@0 ]
[ 4176...@0, 3759...@0, 1892, '\000', 0...@0,
"ELEMENT", "||document", 1...@0 ]
[ 4176...@0, 3759...@0, 0, '\001', 0...@0, "TEXT",
nil, 1...@0 ]
...
End of that document and start of the next one (15792th document in this
case) --- inside the hole instead of on the next page:
[ 4176...@0, 3760...@0, 0, '\002', 119...@0,
"TEXT", nil, 1...@0 ]
[ 4176...@0, 3760...@0, 1638, '\001', 0...@0, "TEXT",
nil, 1...@0 ]
[ 4176...@0, 3760...@0, 284, 'ÿ', nil,
"DOCUMENT", nil, 1...@0 ]
[ 4176...@0, 3760...@0, 283, '\000', 0...@0,
"ELEMENT", "||document", 1...@0 ]
[ 4176...@0, 3760...@0, 0, '\001', 0...@0, "TEXT",
nil, 1...@0 ]
...
Next page boundary:
[ 4177...@0, 3761...@0, 0, '\003', 0...@0, "TEXT",
nil, 1...@0 ]
[ 4177...@0, 3761...@0, 2, '\003', 3...@0,
"ELEMENT", "||actie", 1...@0 ]
Re-assigning to the "Mr. shredder": Jan Flokstra.
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-12-12 12:37
Message:
There might of course be a place in the ll_child implementation where I
forgot to put a check for holes (i.e., highest bit of size value is set...
What I recall is that ll_child and ll_descendant (may be other ll steps as
well) assume that they do receive "sound" and "sane" context sets as input,
i.e., the context sets only contain real (existing) nodes with valid sizes,
but (obviously?) not entries that point to holes ...
----------------------------------------------------------------------
Comment By: Loredana Afanasiev (lafanasi)
Date: 2008-12-12 01:10
Message:
I also bumped the problem with counting:
[lafan...@zookst4 xq]$ mclient -lx -s 'count(pf:collection("HAN")/node())'
19820
(this is the real collection size)
[lafan...@zookst4 xq]$ mclient -lx -s
'count(pf:collection("HAN_Updatable")/*)'
48
[lafan...@zookst4 xq]$ mclient -lx -s
'count(pf:collection("HAN_Updatable")/node())'
19904
[lafan...@zookst4 xq]$ mclient -lx -s
'count(pf:collection("HAN_Updatable")/node()/*)'
19906
----------------------------------------------------------------------
Comment By: Peter Boncz (boncz)
Date: 2008-12-11 23:56
Message:
Stefan: I also asked Lefteris to look at this, but the problem here is that
the child staircase join does not handle NIL tuples that occur in updatable
documents.
It should ignore these, and filter them out.. Could you maybe help?
----------------------------------------------------------------------
Comment By: Peter Boncz (boncz)
Date: 2008-12-09 00:46
Message:
I did:
$ ls | wc
27946 27946 335352
$ ls *xml | awk 'BEGIN { print "<a>"} { printf "<b
p=\"/export/scratch0/boncz/bug/XML/%s\" f=\"%s\"/>\n", $1, $1 } END { print
"</a>" }' > /tmp/g.xml
Then I see that in algebra mode, fn:collection() returns the wrong count
for the updatable collection:
more>for $d in doc("/tmp/g.xml")//b return pf:add-doc(exactly-one($d/@p),
exactly-one($d/@f), "rdonly")
more><>
xquery>count(fn:collection("rdonly"))
more><>
27946
xquery>for $d in doc("/tmp/g.xml")//b return
pf:add-doc(exactly-one($d/@p), concat(exactly-one($d/@f),"_"), "wr", 10)
more><>
xquery>count(fn:collection("wr"))
more><>
28012
That is, the child step does not work correctly from the pf:collection()
node:
xquery>count(pf:collection("wr")/child::text())
more><>
42
xquery>count(pf:collection("wr")/child::attribute())
more><>
0
xquery>count(pf:collection("wr")/child::element())
more><>
38
xquery>count(pf:collection("wr")/child::node())
more><>
28012
(this holds for both mps and alg)
Funny thing is that 27946 + 38 + 42 = 28026, not 28012 ???
I think the child step should be fixed to properly support the collection
node...
----------------------------------------------------------------------
Comment By: Sjoerd Mullender (sjoerd)
Date: 2008-10-07 17:36
Message:
I can reproduce the error in the development version after I loaded all
data. I didn't try the stable version (yet).
----------------------------------------------------------------------
Comment By: Loredana Afanasiev (lafanasi)
Date: 2008-10-03 18:49
Message:
Hi Stefan,
here's the data:
http://staff.science.uva.nl/~lafanasi/data.tgz
and the queries are:
::::::::::::::
tmp1.xq
::::::::::::::
let $col := fn:collection("MotiesTweedeKamer")
let $years := fn:distinct-values(
for $date in $col//hiddendatum
return fn:substring(fn:string($date),1,4))
for $y in $years
order by $y ascending
return <result year="{$y}" count="{
count($col//document[fn:substring(fn:string(.//hiddendatum),1,4) =
$y])}"/>
::::::::::::::
tmp2.xq
::::::::::::::
let $col := fn:collection("MotiesTweedeKamer_Updatable")
let $years := fn:distinct-values(
for $date in $col//hiddendatum
return fn:substring(fn:string($date),1,4))
for $y in $years
order by $y ascending
return <result year="{$y}" count="{
count($col//document[fn:substring(fn:string(.//hiddendatum),1,4) =
$y])}"/>
Thanks,
l.
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-10-01 22:50
Message:
Loredana,
could you please provide us with (e.g., attach) the complete queries, and
possible also with (access to) the document collections you are using?
Thanks in advance!
Stefan
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2141012&group_id=56967
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
