[elephant-devel] fix of ele-postmodern to work with recreate-instance-using-class

[Ian Eslick]

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