dlw@odi.com (Dan Weinreb) (08/18/89)
Scott Simpson of TRW writes:
I believe that when you stick to straight C++, you also lose seamlessness
(that is, you must now use library calls rather than having persistence
built directly in your language). C++ doesn't have keywords for persistence.
You could extend C++, but then it wouldn't be C++.
It depends on what you mean by "seamless". The word is really a
"package deal", referring to a wide range of traits that are
considered desirable. So a particular system isn't necessarily either
seamless or seamful; it's a matter of degree. Here are the most
important things that I'd like to see in a C++ OODBMS, in the area of
integration of the language and the database system.
(1) They use exactly the same type system. Any object and any type
that can be expressed in the language can be expressed in the database
system, and vice versa, without exception, including built-in types,
or classes supplied by a libarary-writer who was not aware of the
existence of the OODBMS (important in the age of reusable code, if and
when it arrives). There should not be any special declaration for
"pointers to persistent" or "pointers to possibly persistent" data as
distinct from ordinary pointers.
(2) All basic language operations are written the same way regardless
of whether the objects that they're operating on are persistent or
transient. ("Transient" means "like a normal C/C++ object", residing
on the heap or the stack or in static memory, disappearing when the
application program is finished.) 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++.
(3) There is no "translation" operation between persistent and
transient objects that the programmer must go through.
In my opinion, a system that achieves these criteria has provided a
useful and high degree of integration between the language and the
database system. Whether it qualifies as "seamless" depends on how
you use the word; I'd say such a system was very much on the
"seamless" side, that it was significantly less "seamy" than many
existing and some proposed systems that I've seen descriptions of.dcmartin@lisp.eng.sun.com (David C. Martin) (08/18/89)
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)quass@polya.Stanford.EDU (Dallan W. Quass) (08/22/89)
David C. Martin writes >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. Check out PCLOS, by Andreas Paepcke. It makes use of the meta-object protocol to provide persistent storage for CLOS objects. One of the goals is to interface to a variety of storage managers, so that you can choose based upon functionality vs. performance. (Currently a main-memory database and IRIS are used as storage managers.) References: PCLOS: A Flexible Implementation of CLOS Persistence 1988 ECOOP PCLOS: A Critical Review 1989 OOPSLA (to appear) Also, someone mentioned how widely differing DBMS's were are being called 'OODBMS's. I agree. However, there is work in progress to try to work out a standard. See "Why Isn't There an Object-Oriented Data Model" by David Maier, to appear in the IFIP 11'th World Computer Congress. In it he summarizes a working paper by Malcolm Atkinson, Francois Bancilhon, David DeWitt, Klaus Dittrich, David Maier, and Stanley Zdonik, called "The Object-Oriented Database System Manifesto," which represents a step in the standardization direction. Dallan Quass quass@eclipse.stanford.edu
dlw@odi.com (Dan Weinreb) (08/22/89)
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