Message 66

Re: question

X-Added: With Flames (bblib $Revision: 1.4 $)
Return-path: <nburns@andrew.cmu.edu>
X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail
Received: from po0.andrew.cmu.edu via trymail for bb+academic.cs.15-721@andrew.cmu.edu
          ID </afs/andrew.cmu.edu/usr0/bb/Mailbox/gvkI=yy00UdY1KpE4j>;
          Mon,  8 Oct 2001 02:09:03 -0400 (EDT)
Received: from mx1.andrew.cmu.edu (MX1.ANDREW.CMU.EDU [128.2.10.111])
        by po0.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id CAA22225
        for <bb+academic.cs.15-721@ams.andrew.cmu.edu>; Mon, 8 Oct 2001 02:09:02 -0400 (EDT)
Received: from surreal (pool-141-158-70-172.pitt.east.verizon.net [141.158.70.172])
        by mx1.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f98691eD030794
        for <post+academic.cs.15-721@andrew.cmu.edu>; Mon, 8 Oct 2001 02:09:02 -0400
Received: from surreal ([127.0.0.1] ident=nburns)
        by surreal with smtp (Exim 3.32 #1 (Debian))
        id 15qTb4-0000ui-00
        for <post+academic.cs.15-721@andrew.cmu.edu>; Mon, 08 Oct 2001 02:09:02 -0400
Date: Mon, 8 Oct 2001 02:09:02 -0400 (EDT)
From: Neal Burns <nburns@andrew.cmu.edu>
X-Sender: nburns@surreal
To: post+academic.cs.15-721@andrew.cmu.edu
Subject: Re: question
In-Reply-To: <3BBAFA17.6010702@cs.cmu.edu>
Message-ID: <Pine.LNX.3.96L.1011008020240.3340C-100000@surreal>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

It is actually impossible to shorten a record because there is no public
method in HFPage that will let you change the record length that HFPage
stores internally. But I assume we don't have to worry about this.

Neal

On Wed, 3 Oct 2001, Spiros Papadimitriou wrote:

> Yes, the design decisions which have already been made for you by the
> Minibase designers aren't always necessarily optimal...  BTW, here is
> a "peek" at a comment from the Minibase implementation:
> 
>   // they tried to update a record with data different in size from the old
>   // record; that's an error since we can't necessarily expand the
>   // old record (to accommodate the extra bytes of the new record), and
>   // we can't pick a new slot/new page for the new record because that
>   // would change the RID: but we can't change the RID because it's const&.
> 
>   // There is no good reason to prohibit updates that shorten a record,
>   // but we do that anyway.
> 
> Now, speaking of optimal decisions...  I think there is some rationale
> behind not changing the RID, at least *without asking* (please, correct me
> if I'm wrong... software design decisions aren't really an exact science,
> after all :-).  What this means isn't that an upper layer cannot update
> a record with a new sized record.  But if that operation will change the
> RID, then one might as well replace it with a deleteRecord()/insertRecord()
> pair and really be prepared for the fact that the RID (which may be used
> in references elsewhere and thus need to be updated there as well) may
> change.  This in turn is closely related to the structure of RIDs.  These
> are page no + slot no, but there could be another level of indirection, so
> RIDs could be transparently changed.  That might impose unnecessary
> overheads, though...  Anyway, just my $.02! :-)
> 
> Spiros
> 
> Deepayan Chakrabarti wrote:
> 
> >Hi
> >  HeapFile::updateRecord accepts a const RID& as a parameter. But while
> >updating, the new record may have to be shifted on to a new page. in that
> >case, the rid should change... why const?
> >
> >Thanks
> >deepay
> >
> >
> 
> 
> 
>