Xref: utzoo comp.object:3648 comp.databases:10377 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!osc!jgk From: jgk@osc.COM (Joe Keane) Newsgroups: comp.object,comp.databases Subject: Re: Schema/Type Evolution in Traditional and O-O DBMSs Summary: We do it. Keywords: schema evolution Message-ID: <4881@osc.COM> Date: 4 Jun 91 00:50:11 GMT References: Reply-To: Joe Keane Followup-To: comp.object Organization: Versant Object Technology, Menlo Park, CA Lines: 43 X-Moon-Phase: Waning Gibbous (66% of Full) In article clamen+@CS.CMU.EDU compiles the following comments: >Versant provides schema evolution. But in the current release, only >leaf classes in the schema can be modified. Leaf classes can be >added, dropped, renamed and individual attributes and methods >changed. The class instances are modified later as they are accessed. >There are no security mechanisms for preventing users from >changing schema. Schema changes are done using a separate utility >which compares files (with .sch extension) which contain new schema >definitions with those of a database and changes the database schema >so that there is no difference. In case of conflicting class names >or other situations user has control on resolving the conflict. >[h.subramanian@trl.OZ.AU] This is an accurate description. >I've been looking at the C++ database vendors. Versant has schema >evolution at the leaf class level only. They're trying to come up with >a good way to do it for the general case. It's true that we currently only support evolution of leaf classes. However, i'd like to point out that this is only an implementation restriction of the current release, and there are no architectural or technical problems with doing it. As a practical matter, i haven't heard our customers complaining about this restriction. I'd guess that if you're changing the design of your base classes, then you have more to worry about than evolving your current databases. >They talk about using >versioning to mark class evolution. Then they want to test timestamps >when an object is retrieved to see whether its class has been changed. >If it has, they reformat the object to conform to the new definition >at that time. >[arc!chet@apple.com] These are all things we do in our released product, with the restriction given above. A minor correction is that we use internal class version identifiers, rather than comparing timestamps. Disclaimer: I work for Versant. -- Joe Keane, professional C programmer jgk@osc.com (...!uunet!stratus!osc!jgk)