[elephant-devel] fix of ele-postmodern to work with recreate-instance-using-class
Ian Eslick
eslick at csail.mit.edu
Wed Jan 9 15:26:32 UTC 2008
On Jan 9, 2008, at 4:02 AM, Alex Mizrahi wrote:
> the problem was actually quite easy -- pm-btree needs to initialize
> it's
> transient each time it's created or deserialized. it participates
> both as
> descendant from "persistent" as pm-btree itself, and as persistent-
> object in
> form of pm-indexed-btree.
I think the original idea is that persistent-collections are special
and not supposed to be persistent-objects, but this conflicts with the
default behavior of the persistent-metaclass 'ensure persistent-
object' functionality. This may have been some of the problem.
> (so pm-btree is quite a good test for a new system)
>
> as we've found out, now initialization of transient slots should be
> done in
> shared-initialize :after (it's funny, nobody have replied directly
> to my
> concrete question, but it was mentioned in some 'proposals').
This is how it was done for bdb-indexed-btree
> unfortunately original implementation of recreate-instance-using-class
> deprives "persistent" from any kind of initialization, including
> shared-initialize. i believe it's a bug and recreate-instance-using-
> class
> either should call normal make-instance for everything except
> persistent-object. or, at least, it should call shared-initialize.
make-instance for standard classes is probably just fine; although
this may have some of the same problems - that an object init function
is called on each deserialization. Still, this is normal since
standard classes really are 'recreated' when retrieved from the store
as they haven't been made 'persistent' and so users should design
their systems accordingly. As you note below, this handles the
missing case of initializing persistent for non persistent-metaclass
objects that are persistent (i.e. persistent-collections)
>
> (again, this was in my original question but nobody addressed this
> issues
> directly. is my English that poor so nobody understand me??).
I think part of the problem is that none of us have our heads around
all the details you've been working on so intimately. I've found that
usage of the MOP leads to the need to model alot of hidden state. It
takes me awhile to remember all the details since it's been almost a
year since I worked on this part of Elephant in earnest.
In general, you seem to be uncovering some real problems with the
semantics and use of persistent, persistent-object and persistent-
collection and their interaction with persistent-metaclass.
btrees are standard-classes that also have 'persistent' on them so
they get serialized properly as OID + class, but don't have the slot
protocol defined on them so aren't persistent-objects or part of the
persistent-metaclass (they aren't indexed, etc).
Since indexed-btrees need to have an additional persistent parameter,
they were made a persistent-metaclass which means they inherit from
both persistent-collections and persistent-object.
persistent-objects should get initialized via (shared-initialize
instance (transient-slot-names (class-of instance)) ...) to initialize
only the transient slots (this will catch pm-indexed-btree slots but
not cause initforms to be re-evaluated for any unbound persistent slots.
I think this is inline with the general idea, but it would be nice to
hear what the correct semantics of the subclasses of persistent and
their interaction with persistent-metaclass should be! You're
probably the most qualified to answer this now.
I don't have a strong opinion about how this should be fixed, but
let's make sure we aren't hacking up the initialization to fix a
fundamental problem with the use of the class hierarchy. It might
make more sense if we make indexed-btrees not inherit from persistent
objects...but that would mean special functionality is needed from
every data store to maintain persistent properties and values attached
to persistent-collection objects...
If the distinction isn't useful, we should just collapse everything to
'persistent'.
> so, fix consists of two parts:
> 1. `persistent' gets normal initialization via make-instance (i've
> already
> posted code), so pm-btree has chance to initialize itself;
This sounds right.
> 2. initialize-instance :after of pm-btree is changed to shared-
> initialize
> so it will work for pm-indexed-btree which is persistent-object.
This is good.
> does this make sense according to original design? if it does, i'll
> send a
> patch.
>
> if part 1 is against the spirit of this recreate thing we can just add
> shared-initialize call in recreate-instance of `persistent'.
> i don't see how it will change anything though..
>
> p.s. fixing this was somewhat complicated because it didn't clearly
> report
> problem that pm-btree is not initialized, but tried to initialize
> itself in
> erroneous and confusing way in some obsoleted code path. i'm going
> to delete
> these code pathes, so we won't be confused if something like that
> happens
> again
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
More information about the elephant-devel
mailing list