One small update, as I have made a mistake in my initial mail : Le 3/13/13 10:25 AM, Emmanuel Lécharny a écrit : > Another thing : the fact that BTree headers might span across two > pages is really annoying : we can have a crash after having updated > the first page but before updating the second one, leading to > inconsistencies. An option would be that each BTree header is stored > in one single page, so that we always store those informations in one > single page.
A BTree is always written in a new page. What happens is that we flush a BTree, then we flush the rootPage, so the next BTree starts on a new page too, just after the previous BTree's rootPage : [BTree1 header pages][Btree1 root pages][BTree2 header pages][Btree2 root pages]...[BTreeN header pages][BtreeN root pages] Now, there is still a problem with this approach : if we add a new BTree in the RecordManager, after having added many element sin the existing BTrees, we won't be able to find this newly added BTree unless we have read all the existing BTrees' pages, which is simply impossible. Here, we need to create a link between the Btree headers (so when we add a new BTree, its header will be pointed by the previous BTree. One solution would be to store the offset of the next btree header in each header : BH1:[header, BH2 ref] ... BH2:[header, BH3 ref] ... BH3:[header, BH4 ref] ... /// ... BHN-1:[header, BHN ref] ... BHN:[header, null] Adding a new BTree will require the program to move from header to header, up to the last one, then we will have to update the last header to point to the added header. Removing a BTree will be a matter to find the previous header and make it point to the next header. It's not implemented atm, will work on that. Any better idea ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
