Bugs item #2153245, was opened at 2008-10-08 15:53 Message generated for change (Settings changed) made by tsheyar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2153245&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 CVS Head Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lefteris Sidirourgos (lsidir) >Assigned to: Sjoerd Mullender (sjoerd) Summary: XQ: corrupted document after replace node Initial Comment: After shredding the attached document2.xml and running the 4 update queries in the attached xquery2.xq file the document gets corrupted. Update query #3 tries to replace a node with a new one. However it fails to do so, the resulting document has at the end: <folder name="lsidir"> <bookmark-definition name="Third comment" project="*" shared="true"> <query/> </bookmark-definition> </folder> when it should have: <folder name="lsidir"> <bookmark-definition name="Third comment" project="*" shared="true"> <query/> <description>Description One</description> <note>Note 1</note> </bookmark-definition> </folder> The forth query mess up the document even more, but most notable it makes description and note elements to re-appear with wrong attributes and wrong nesting: <folder name="lsidir"> <bookmark-definition name="Third comment" project="*" shared="true"> <query/> <bookmark-definition shared="true" project="*" name="CopyOf Third comment"> <query/> <description name="Third comment" project="*" shared="true">Description One</description> <note>Note 1</note> </bookmark-definition> </bookmark-definition> </folder> the correct output should be: folder name="lsidir"> <bookmark-definition name="Third comment" project="*" shared="true"> <query/> <description>Description One</description> <note>Note 1</note> </bookmark-definition> <bookmark-definition shared="true" project="*" name="CopyOf Third comment"> <query/> <description>Description One</description> <note>Note 1</note> </bookmark-definition> </folder> ---------------------------------------------------------------------- >Comment By: Jan Rittinger (tsheyar) Date: 2008-10-13 16:13 Message: Sjoerd, I added your proposed fix to the algebra. Please have a look if everything works as expected. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2008-10-09 17:08 Message: Jan, I am assigning this to you since the bug isn't quite fixed yet, and I'm afraid it's in the algebra generation where it goes wrong (i.e. before this gets to UpdateTape). There are two problems in the algebra generation, one serious, one performance. The performance problem is that you should use the function get_attr_own to query the ATTR_OWN table. ATTR_OWN consists of a shared and a private part (because of updates), and the shared part has a hash to speed up accesses. The function knows how to deal with this. Direct access to ATTR_OWN does not use the hash. The real problem is a confusion between PRE numbers and NIDs. This happens in milgen.brg around line 6878 (stable branch). Here is some MIL code that shows what should be generated: a0003 := select(a0005.fetch (7),oid_nil,oid_nil); var x := a0003.hmark([EMAIL PROTECTED]).leftfetchjoin(a0005.fetch (8)); a0003 := get_attr_own(ws, mposjoin(a0003.tmark([EMAIL PROTECTED]), x, ws.fetch(PRE_NID)), x); This should come in place of the line which is actually generated by the referenced code: a0003 := mvaljoin (a0005.fetch (7), a0005.fetch (8), ws.fetch (ATTR_OWN)); What is done here is to remove the nil values from the PRE table (why are there nils anyway?) and then use mposjoin to look up the PRE values in the PRE_NID table to translate them to NID values. Note that this fixed code also uses get_attr_own already. Peter and I don't know how to integrate these changes into milgen.brg. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2008-10-09 11:44 Message: Fixed. The problem was indeed the replace query. Internally it first deletes the node being replaced and then inserts the new node. When inserting the new node, it didn't adjust the ancestor sizes since all ancestors now ended with a hole which was created by the deletion, and the check whether the ancestor sizes needed to be adjusted didn't cater for them ending with a hole. Lefteris can you check the stable output that I provided with the test. The test was added in tests/Update as replacenode-corruption.SF-2153245. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2153245&group_id=56967 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
