Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ginosko!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.databases
Subject: Re: Seamless integration with an OODB
Message-ID: <1989Aug21.200905.1541@odi.com>
Date: 21 Aug 89 20:09:05 GMT
References: <1989Aug17.205901.28760@odi.com> <DCMARTIN.89Aug18085127@lisp.eng.sun.com>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 48
In-reply-to: dcmartin@lisp.eng.sun.com's message of 18 Aug 89 15:51:27 GMT

In article <DCMARTIN.89Aug18085127@lisp.eng.sun.com> dcmartin@lisp.eng.sun.com (David C. Martin) writes:


   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.

As we see it, the "pointer swizzling" (conversion between the
persistent form of a pointer and the virtual memory form) should be
done transparently by the OODBMS, in order to provide smooth
integration with the language.  As an application programmer, you
should never have to worry about persistent versus non-persistent
pointers.  You just write your program the way you would write any C++
program, and the right thing happens.  Furthermore, this should work
for any type in C++, including built-in types.  This is important
because it makes it easy to import reusable C++ code and use it in a
database-based application.  The Exodus E language, as you point out,
does not have these properties.

   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.

As Jack said, a pointer in C or C++ just points at one address.
Whether dereferencing a pointer immediately brings in a whole large
amount of stuff or a minimal amount of stuff is something that the
application needs to have control over.  In the OODBMS literature (and
a lot of conventional database literature), there's a lot of
discussion about control of "clustering", prefetching, etc., and all
these things can be important for good performance when large amounts
of data are involved.

   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.

Lisp is so different from C++ that it's hard to know where to begin.
I agree that the CLOS meta-object protocol would be useful in
implementing a Lisp-based OODBMS.  Statice could have been implemented
somewhat more elegantly had the meta-object protocol been available,
although I think only a small fraction of the Statice code would be
affected.

Dan Weinreb		Object Design, Inc.		dlw@odi.com