bPlusCreate getting record doubt

[Ruben Jacob]

Hi,

In bPlusCreate the roadmap tells us to get each record to insert directly by using the getRecord function of BlockBuffer. Can't we simply use BlockAccess::project to get every record instead. 

[C M MADHAV PRABHU]

Hey, this sounds good on paper, just confirm that the linear searchIndex isnt touched by bPlusInsert or somewhere else in bPlusCreate. Would appreciate more comments.

On Thu, 26 Oct 2023, 22:13 Ruben Jacob, <rubenj...@gmail.com> wrote:

Hi,

In bPlusCreate the roadmap tells us to get each record to insert directly by using the getRecord function of BlockBuffer. Can't we simply use BlockAccess::project to get every record instead. 

--
You received this message because you are subscribed to the Google Groups "NITCbase Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nitcbase-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/nitcbase-users/87552d20-1ed9-4f45-921e-cb0149e2fc37n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Murali Krishnan]

Can Amal, Nazni and Hatim have a look at this suggestion and give a second opinion.  

To view this discussion on the web, visit https://groups.google.com/d/msgid/nitcbase-users/CAOHzWYwWtLLoMfr3Ek9B7dL8A50P%2BKHcPjArQ0KjXoMMoZAKiw%40mail.gmail.com.

[HATIM SHAKIR]

Hey! If I understand your query correctly, you mean inserting records into the leaves at the time of creating a BPlusTree. A simple project does not work simply because it will insert everything in the order it is present in the original relation. But for a BPlusInsert, the records in the leaves should be in SORTED order. Thus, a simple project is not equivalent to a BPlusInsert for general relations. I hope this answers.

[Ruben Jacob]

I was talking about this section in bPlusCreate

while (block != -1) {

// declare a RecBuffer object for `block` (using appropriate constructor)

unsigned char slotMap[relCatEntry.numSlotsPerBlk];

// load the slot map into slotMap using RecBuffer::getSlotMap().

// for every occupied slot of the block
{
Attribute record[relCatEntry.numAttrs];
// load the record corresponding to the slot into `record`
// using RecBuffer::getRecord().

// declare recId and store the rec-id of this record in it
// RecId recId{block, slot};

// insert the attribute value corresponding to attrName from the record
// into the B+ tree using bPlusInsert.
// (note that bPlusInsert will destroy any existing bplus tree if
// insert fails i.e when disk is full)
// retVal = bPlusInsert(relId, attrName, attribute value, recId);

// if (retVal == E_DISKFULL) {
// // (unable to get enough blocks to build the B+ Tree.)
// return E_DISKFULL;
// }
}
In this, we are getting each occupied slot from a block. Isn't this what project does? So can't we just give while(BlockAccess::project() == SUCCESS) to get each record instead of manually checking slotmap here. The issue I find (and I am just now realizing this) is that we won't get rec-id using project. So is that why we do this manually instead of project()? So, if we modify project() to return rec-id this could be a possible fix. 

[HATIM SHAKIR]

Okay, I understand. Two things here:

1. You would not need to modify Project itself as well. It stores the recId in RelCacheTable entry and you can easily find it from there.

2. What I think is the reason is, it's the DESIGN itself. If you look carefully, BlockAccess calls BPlusTree, but BPlusTree does not call BlockAccess, solely because that's how the object-oriented design is laid out. Also note that, it is completely possible for you to do so, I have tested the same, but we don't because that's how the design is laid out. Higher level modules will call lower level modules, but not vice-versa. 

Hope this helps. 

[HATIM SHAKIR]

Sorry for the spam, but here's the design for your reference :)

https://nitcbase.github.io/docs/Design/Architecture