Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!sun-barr!sun!dcmartin From: dcmartin@lisp.eng.sun.com (David C. Martin) Newsgroups: comp.databases Subject: Re: Seamless integration with an OODB Message-ID: Date: 18 Aug 89 15:51:27 GMT References: <1989Aug17.205901.28760@odi.com> Sender: news@sun.Eng.Sun.COM Reply-To: dcmartin@sun.com Organization: Sun Microsystems, Inc Lines: 43 In-reply-to: dlw@odi.com's message of 17 Aug 89 20:59:01 GMT Dan Weinreb of ODI writes: There should not be any special declaration for "pointers to persistent" or "pointers to possibly persistent" data as distinct from ordinary pointers. It would be nice if no one ever had to consider if a pointer was persistent or non-persistent, but someone will have to build the access methods and other low-level interface routines to your storage manager in order to provide this type of "pointer swizzling" to the application developer. At UW - Madison the Exodus Project is developing a language called E, which is a persistent C++ language designed to allow an individual to write an her own access methods, and to a certain extent pointers to resident objects are equivalent to persistent. However, for this equivalency the pointer types must be DB pointers, i.e. dbchar* != char*, but a persistent dbchar* is equivalent to a non-persistent dbchar*. In particular, de-referencing a pointer has exactly the same semantics and syntax regardless of whether the objects are persistent or transient. In general, data manipulation (storing, fetching, testing, adding, printing, field extraction, function calling, casting) looks exactly as it does for normal C++. What about dereferencing a pointer to a 40mb image? Does this mean bringing the entire image into core? There must be some low-level routines to allow the application programmer to inform the language that certain special methods should be used to store, fetch, etc... for special datatypes. I enjoyed your paper on Statice, and I agree that there are several problems with the dual language approach which RDBMS vendors utilize. One language I have not seen discussed here is Common LISP and CLOS. With the introduction of the meta-object protocol appendix, it seems that this language environment would be most suitable for an OODBMS front-end to a robust storage manager. dcm -- ----- Stupidty got us into this mess; why can't it get us out? - Will Rogers ----- David C. Martin arpa: dcmartin@cs.wisc.edu University of Wisconsin - Madison uucp: uunet!ucbarpa!dcmartin Computer Sciences Department at&t: 608/262-6624 (O)