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
> >
> >
>
>
>
>