[rucksack-devel] Some other things

[Arthur Lemmens]

Levente Mészáros wrote:

> I have some other questions not directly related to export. Is it
> planned to support weak references?

I'm not sure what that would mean in the context of Rucksack.  Could
you explain what this would mean and why you would want them?  Somehow
a persistent weak pointer sounds like a contradiction in terms to me,
but that's probably just my lack of imagination.

> I implemented the serialization of structures using SBCL, this was
> fairly trivial dispatching on structure-object. I did not look at
> other implementations but will you include such patches?

Hmm, difficult question.

I'd like Rucksack files to be portable between CL implementations, so
you can create a rucksack with one implementation and load it with another
implementation later.  I'd also like Rucksack files to be self-describing,
so that it's possible to recreate all persistent data even if you don't
have the source of the program that created the data.

These goals are both difficult to achieve, but I try to keep them in
mind when working on Rucksack.

When we add support for serializing structures, I think we need a way to
detect and record changes to structure definitions, similar to what
Rucksack does for classes of metaclass PERSISTENT-CLASS.  We'd have to
detect the changes, add the diffs to the schema table, etcetera.  Otherwise
the data in a rucksack will become useless as soon as the programmer
changes one DEFSTRUCT form in his program.

The problem is: I suspect that this (handling changes to structure
definitions) will be impossible to achieve in many (most? all?) CL
implementations.  And I'd rather not add it to Rucksack for one CL
implementation if it's obvious that it will never be implemented for most
of the others.

But if you can implement this in SBCL and can show that it will be possible
to implement in a few other implementations, I'll gladly add it to Rucksack.

> I also noticed that some slots (rucksack/transaction/etc.) of
> persistent classes are persistent-effective-slot-definitions even
> though they should not be. I guess this can be fixed in
> direct-slot-definition-class and effective-slot-definition-class by
> checking on the persistence flag.

I don't really understand what you mean.  Could you be more specific?

> I tried to implement a persistent base class called audited-object
> which stores the time of creation, the time of last modification, last
> modifier, etc. In principle an :after method on (setf
> slot-value-using-class) could make it, but unfortunately I could not
> distinguish between code setting the persistent slot outside of
> rucksack and code internal to rucksack itself. Maybe rucksack could
> use a function slot-value-using-class-internal which would bind a
> special variable so that overriding svuc will be able to distinguish
> between loading the object from the disk and setting a slot value by
> the user.

Yes, interesting idea.  I'd be inclined to create a new metaclass,
say AUDITED-PERSISTENT-CLASS which inherits from PERSISTENT-CLASS, and
define a new SETF SLOT-VALUE-USING-CLASS method for classes of that
metaclass.  Your new method could then do tricks with special variables
(if that's really necessary).

> While I like the way with-transaction works I think most of the time
> user code will not pass in any parameters to it (see tests for
> example), so maybe it would be better to call the current one
> with-transaction* and introduce another one without any parameters
> called with-transaction. What's you opinon about this?

You mean you don't like the extra pair of parentheses after
WITH-TRANSACTION? Like

  (with-transaction ()
    (foo)
    (bar))

I love that empty pair of parentheses.  They give me a feeling of
closure...

Arthur