[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Persistent Objects
- To: Zachary Smith <edsel!zach@labrea.stanford.edu>
- Subject: Re: Persistent Objects
- From: David C. Martin <dcmartin%postgres.Berkeley.EDU@Berkeley.EDU>
- Date: Tue, 15 Mar 88 14:58:52 PST
- Cc: edsel!lgd@labrea.stanford.edu, commonloops.pa@Xerox.COM, edsel!rpg@labrea.stanford.edu
- Email: dcmartin@postgres.Berkeley.EDU or {ihnp4,decvax}!ucbvax!dcmartin
- In-reply-to: Your message of Tue, 15 Mar 88 12:23:28 PST <8803152023.AA17969@bhopal.lucid.com>
- Organization: University of California at Berkeley - Dept of EECS/CS Division
- Phone: 415/642-9585 (O)
- Redistributed: commonloops.pa
- Sender: dcmartin%postgres.Berkeley.EDU@Berkeley.EDU
We (the Object FADS - for lack of a better name) group have been using the
POSTGRES database to do exactly what you are talking about. One of the
graduate students (ywang@postgres) has written a shared object hierarchy
which allows some of these features. I am working on version control and
storing sexp's to recreate arbitrary CLOS objects (ie. objects which are
not shared, but must be recreated when loading a shared object).
As for storing aribitrary lisp in a database, you should look at Margaret
Butler's PhD thesis: _Persistant LISP: Storing Interobject References
in a Database_, UCB/CSD 88/401.
Hope this helps.
dcm
--------
Your message:
I am real interested in whatever is currently available on the persistent
objects concept. Has anyone written any papers about this? In particular,
I am proposing a system where large bodies of structured text (usually
but not necessarily programs) are represented in the running image by
CLOS objects. These objects also have to be organised into a database
with locking, version control, read-write access control and the like.
I understand that someone is planning on extending CLOS to include some
or all of this kind of thing and I'd dearly like to know about it.
Thanks,
--------