[rucksack-devel] Re: Rucksack, ECLM

[Arthur Lemmens]

Nikodemus wrote:

>   I am, however, a bit confused on what is the intention in the
>   following cases:
>
>     (defclass x ()
>       ((y :persistence t :accessor y-of))
>       (:metaclass persistent-class))
>
>     (let ((x (make-instance 'x)))
>       ;; OK so far -- X may is potentially persitent, but not reachable
>       ;; from any root-set or index, so no problems.

Actually, I think this is not OK so far.  I think you shouldn't
MAKE-INSTANCE a persistent object unless there is an open current-rucksack
(which is created by WITH-RUCKSACK, or maybe by
(SETF (CURRENT-RUCKSACK) (OPEN-RUCKSACK ...)).

When X is created, the RUCKSACK slot of X is bound to this rucksack.  And
Rucksack should probably signal an error at this point if there is no
current rucksack.


>       (with-rucksack (r *my-rucksack*)
>         (with-transaction ()
>           (add-rucksack-root x r)))
>       ;; Still OK

If R is the same rucksack as the RUCKSACK slot of X, there's no problem
here.  Otherwise, I think an error should be signaled at this point.

>       ;; In either case, another hairy case follows:
>       (with-rucksack (r *other-rucksack*)
>          (with-transaction ()
>            (add-rucksack-root x r)))
>       ;; ...either this should signal an error because the rucksack is wrong,

Yes, I think that's what should happen (see above).

>       ;; transport the object from *my-rucksack* to *other-rucksack*

I do want to provide for copying objects from one rucksack to another, but
I don't think that this should happen automatically, because it's not a
trivial thing to do.  Do we want a deep copy (so we could copy an entire
rucksack by just copying the roots) or a shallow copy, for example?

We'd probably want a function like

(defgeneric rucksack-import-object (rucksack persistent-object &key deep-copy))

But this is not on the top of my list.

>       ;; multiple Rucksacks per object should be allowed -- in which case
>       ;; later pulling X from *my-rucksack* and updating it should also update
>       ;; the X in *other-rucksack*.

That sounds like a nightmare to me.  But maybe that's just because I haven't
thought about scenarios like that yet.

>      Is a single Rucksack a "universe" or a "container"?
>
>   If a Rucksack is a universe, then it would make sense to enforce
>   certain restrictions on that universe: eg. you cannot assign objects
>   belonging to other universes to persistent slots.

Yes, that's what I have in mind.  I do think that it should be possible
to work with multiple rucksacks at the same time, but I think there
shouldn't be persistent connections between rucksacks.  You *can* have
non-persistent connections, for example a non-persistent object that
contains objects from different rucksacks.  And at a later stage I want
to provide for some functions to copy/migrate objects from one rucksack
to another.

>   In the universe case there is a relatively simple option that might
>   untangle some things: make Rucksack a property of a class.
>
>    (defclass foo-class (persistent-class) ()
>      (:default-initargs :rucksack "/var/rucksacks/foo/"))

Hehe.  Interesting idea.  But then you can't migrate or copy objects
between rucksacks anymore, can you?


Interesting questions, these.  I'm not saying that my answers are the
best ones, I'm just explaining what I had in mind for Rucksack.  If you
think that another approach would work better, please let me know.

By the way: something that I *would* like to do sooner or later
(probably later ;-)) is to have distributed rucksacks: one rucksack
distributed over more than one machine.

Arthur