Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!pp!nebula!ballou
From: ballou@nebula.ACA.MCC.COM (Nat Ballou)
Newsgroups: comp.databases
Subject: Re: OO DBMSs (was Re: Extended RDB vs OODB)
Summary: Schema evolution
Message-ID: <311@nebula.ACA.MCC.COM>
Date: 25 Aug 89 16:25:00 GMT
References: <3560052@wdl1.UUCP> <411@odi.ODI.COM> <19@dgis.daitc.mil> <1989Aug21.132525.3179@odi.com>
Organization: MCC, Austin, TX
Lines: 27

In article <1989Aug21.132525.3179@odi.com>, jack@odi.com (Jack Orenstein) writes:
> We are very familiar with the Exodus project, and with the E language.
> While the type system of E is far preferable to that of a typical
> host-language/DBMS combination, it still has two distinct, but
> "parallel", type systems, and programmers have to be careful about the
> use of db types. In our product, there will be a single type system,
> that of C++. There is no fundamental reason why persistent and
> transient types have to be distinguished in the language used by the
> application programmer.
> 

I am interested in how the Object Design people intend to do schema
evolution in their forthcoming system.  Suppose I make a persistent subclass
of a non-persistent class.  I then go on to populate the persistent class.
How does one add/drop attributes, superclasses, indices, etc.  If a
non-persistent superclass of my persistent class changes (i.e., an
attribute/method is deleted/added, etc.) what happens to the instances in
the database.  Will all programs compiled against the schema have to be
recompiled after such a change?  I'm more interested in semantics and theory
than in implementation details.

> Jack Orenstein
> Object Design, Inc.

Nat Ballou
Orion Project
MCC