You may want to also test the situation where the <id> is duplicated in the
update.
<docs>
<doc>
<id>A00001</id>
<data>some data...</data>
<id>A00001</id>
<data>some update data...</data>
</doc>
</docs>
-----Original Message-----
From: Ivan Shcheklein [mailto:shchekl...@gmail.com]
Sent: Thursday, September 15, 2011 5:04 AM
To: Malcolm Davis
Cc: sedna-discussion@lists.sourceforge.net
Subject: Re: [Sedna-discussion] Possible cause of db corruption?
Hi Malcolm,
Thank you for this details. Normally, index works fine with duplicate keys
in one node (it should return the same document for index scan with A00001
and A00002). However, it's not quite common use case. Moreover, it's a
really good point to test updates with duplicate keys since you don't have
problems now. We'll check it ASAP.
Ivan Shcheklein,
Sedna Team
I may have determined the root of my db corruption problem.
Background
a. A doc.xml file is loaded
b. Several indexes are created on doc.xml
c. Later, update/inserts are done to the doc.xml
Indexes work correctly for data in the initial loaded doc.xml.
Indexes queries fail for data in the updated portion of the doc.xml.
(XQuery index, where/filtering, index-scan and index-scan-between cannot be
used against updated data.)
Issue
The partial of the doc.xml that is updated/inserted breaks the index
because of the layout of the xml. The new xml portion has multiple <id>
blocks that are being used to create the index.
The following is a demonstration of the problem:
Initial xml
<docs>
<doc>
<id>A00001</id>
<data>some data...</data>
</doc>
</docs>
Later an update is done, but the <id> is duplicated in the doc
format.
<docs>
<doc>
<id>A00001</id>
<data>some data...</data>
<id>A00002</id>
<data>some update data...</data>
</doc>
</docs>
Normally the invalid XML just breaks the portion of the doc with the
duplicated <id>, but I wonder if the continuous updating on the different
indexes over a variety of documents could cause a database index corruption
problem that impacts the entire db.
After fixing the problem, we have not seen any more db corruptions,
but our experiences might be a consequential and not related.
Sorry for all the noise on the subject,
Malcolm
----------------------------------------------------------------------------
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry® mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry® DevCon
today!
http://p.sf.net/sfu/rim-devcon-copy1
_______________________________________________
Sedna-discussion mailing list
Sedna-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sedna-discussion
------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
Sedna-discussion mailing list
Sedna-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sedna-discussion
