[rucksack-devel] Et tu, prevalence?

[Arthur Lemmens]

Nikodemus wrote:

> Perhaps what is needed is prevalent-class/object in addition to
> persistent-class/object? (Referring to "lightweight" in-memory
> prevalence with write-ahead logging and recovery: it isn't as suitable
> for server/client division or distribution like "proper persistence",
> and isn't as good with parallelism... but you can hold on to
> references outside transactions, and they are always EQ.)

Would these prevalent objects be in the same rucksack as persistent
objects or would prevalence vs. persistence be a choice that you
make when you create a rucksack?

> I can certainly understand if this is deemed a bad idea / outside
> the scope of Rucksack, but I for one would find such a pairing
> natural along with providing a low-level serialization API.
>
> What do you think?

Sounds OK to me.  I built a prevalence-like system before I started
working on Rucksack, and I think it would be relatively easy to
add prevalence to Rucksack (as long as prevalent and persistent
objects don't need to coexist in the same rucksack).

I wouldn't want to reuse my existing prevalence library for this
because some of the design choices don't combine well with Rucksack.
But with the serializer and MOP hooks already in place, it wouldn't
be too much work to serialize all changes to a log file and 'replay'
the logfile when loading a prevalent rucksack.

My library didn't handle 'schema evolution' very well: it just ignored
references to slots that didn't exist anymore in the current class
definition and gave new slots a value based on their initform.  If
you want to implement some kind of UPDATE-PREVALENT-OBJECT-FOR-REDEFINED-CLASS
protocol (which would be the proper way to handle class changes, I
think), you'd have to save class definitions in the log file too.

> (In any case, I've come to my senses and have no desire to hold
> references to persistent-objects outside transactions anymore.)

Good ;-)

Arthur