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)