Message 43

Re: question

X-Added: With Flames (bblib $Revision: 1.4 $)
Return-path: <spapadim+@cs.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/EvijcOm00UdYIFc04U>;
          Wed,  3 Oct 2001 07:44:26 -0400 (EDT)
Received: from mx3.andrew.cmu.edu (MX3.ANDREW.CMU.EDU [128.2.10.113])
        by po0.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id HAA04508
        for <bb+academic.cs.15-721@ams.andrew.cmu.edu>; Wed, 3 Oct 2001 07:44:26 -0400 (EDT)
Received: from iluvatar.dhs.org (pool-151-201-19-40.pitt.east.verizon.net [151.201.19.40])
        by mx3.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f93BiObT028670
        for <bb+academic.cs.15-721@andrew.cmu.edu>; Wed, 3 Oct 2001 07:44:24 -0400
Received: from cs.cmu.edu (iluvatar.hobbiton.cmu.edu [192.168.0.2])
        by iluvatar.dhs.org (Postfix) with ESMTP
        id 8BDFB204E8; Wed,  3 Oct 2001 07:44:24 -0400 (EDT)
Message-ID: <3BBAFA17.6010702@cs.cmu.edu>
Date: Wed, 03 Oct 2001 07:44:23 -0400
From: Spiros Papadimitriou <spapadim+@cs.cmu.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010808
X-Accept-Language: en-us
MIME-Version: 1.0
To: Deepayan Chakrabarti <deepay@cs.cmu.edu>
Cc: bb+academic.cs.15-721@andrew.cmu.edu
Subject: Re: question
References: <Pine.LNX.3.95L.1011002172810.12121A-100000@snapdragon.cald.cs.cmu.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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