Re: Need persistent object store/o.o.d.b.

[lynch@aristotle.ils.nwu.edu (Richard Lynch)]

>For my masters project I need a persistent object store because the
>project is object oriented (surprise) and I want to save the objects
>across sessions. In an earlier request I received pointers to Object
>LISP and CLOS function for saving objects to (and loading them from)
>files.  However, it would be much better to have a persistent object
>store (or object oriented database). I need one which has these
>features (I'm new to the persistent object world so please forgive my
>needing to make them explicit):
God, this sounds familiar.  :-)
I'm doing the same thing for *my* MS project.
I have started coding it myself, and will send you what I have so far in
case you decide to bite the bullet and do it yourself.  If you like it, I
can even send you updates as I progress.  [Fair warning, I am NOT under the
gun to get this thing done...]

>- load objects on call (no waiting for an entire file to load and
>  better use of memory: not all objects must be loaded and some can be
>  unloaded if memory gets tight). Ditto for saving.
Check.  See below for details.

>- distributed store (don't have to know the details of where objects
>  are stored and you get transparent network access).
Well, *I* know where they are stored, but the top-level program won't.  :-)

>- concurrent object access + security (can protect objects based on user)
You could modify the code to do this fairly easily.
(Sure.  That's what they all say.)

>- fast saving, loading, and memory access
Save:
  Appends the object's slot-values in a data file.
  Appends the object's name, type, and its starting file-position (in the
data-file above) into an index file.
  Time-stamps the object as saved.

Load:
  Startup load loads only an object's name, type, and file-position from
the index file.
  On-call load looks at the correct number of slot-values starting at
file-position to load in the slot-values.
  [The number of slots is pre-determined by the object's type.]


Memory access:
  There are two kinds of slots:
     1.  Those that hold a single value, and
     2.  Those that hold a list (ie set) of values.

         Single-value slots:
         a.  If the type of the object is known at compile-time, you can
use
             (sv type-name object slot-name)
             Which macroexpands into an svref on a structure reference with
a known offset.

         b.  If the type is not known at compile-time, you must use
             (slot-value object slot)
             Which macroexpands into an svref, a position O(10) elements,
and a couple structure lookups.
         c.  Have if-set methods which are automatically called whenever a
slot-value is altered.
         d.  Both sv and slot-value are known to setf.


         Multiple-value slots (lists, not real multiple-values):
         a.  Are read by an elements macro.  (I've forgotten if this is
like sv or slot-value.)
         b.  Are altered by add-element and delete-element macros.
         c.  Have if-added and if-deleted methods which are automatically
called whenever add-element or delete-element is called, respectively.


   Of course, EVERY memory write calls (get-universal-time) and sets a
structure slot so that the load-on-call can work, but I couldn't think of a
cheaper way to do this.  :-(
   Haven't exactly worked out who decides when to siphon off some of the
objects to cold storage, but the time stamp looks real helpful in tell WHO
to get rid of.  Probably N% of the objects with the stalest write times.

Seems pretty fast to me, but I'm not too sure about this yet.


Am considering the possibility of doing dumplisp (yep, that's me asking
those questions about my work project, as opposed to my MS project) in the
MS, but know I'll regret it when the size becomes prohibitive.  Have
already reached that point at work, and home computer has even less memory,
but isn't so far along.  The object system at work does NOT have load on
call.

PS  What is your project?  I'm working on a program that will find the
optimum arrangement of teachers and periods for a high school.  (Optimum in
the sense of providing educational service to the students using existing
resources of teachers and rooms.)

"TANSTAAFL" Rich lynch@aristotle.ils.nwu.edu