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@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
