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&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the
> BlackBerry&reg; mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry&reg; 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

Reply via email to