[elephant-devel] recreate-instance-using-class

Tue Jan 8 14:41:35 UTC 2008

I agree completely with Ian.

In fact I have now spent a very embarrassing 5 days trying to modify the
ele-postmodern interface to use "recreate-instance" based on Sean's
patches, and have failed miserably.  This is the first time in my career
this has ever happened to me.

I wasted this time in part to learn about postmodern, and in part
because I didn't want to reject Sean's patch, which apparently he and
one other person need.  However, it seems clear now that we need to back
Sean's patch out of the repository and answer more of the questions that
Ian raises.  In particular, it was never perfectly clear to me why Sean
thought avoiding the call to "make-instance" was so important.  I
understand of course that if one has overloaded make-instance with some
functionality that has nothing to do with reconstituting the object, the
current implementation of Elephant will erroneously invoke that; but it
is not clear if Elephant should change to suit that, or if the user
should simply move that functionality out of make-instance.  That is
part of the policy question we will have to answer.

On Tue, 2008-01-08 at 08:50 -0500, Ian Eslick wrote:
> Hi Alex,
> 
> I don't think any of the current developers have sat down and really  
> thought through how the entire MOP interface _should_ work in light of  
> our learning.  My guess is that getting all this right can best be  
> accomplished by rationally designing all the functionality from  
> scratch, and rewrite the persistence protocol as necessary to  
> accommodate the new design.  I learned the MOP during my rewrite a  
> year or two ago, so I'm sure there is some evidence of this in the  
> current implementation.  With the expanded test suite, debugging the  
> new MOP implementation shouldn't be overwhelmingly problematic.
> 
> There are several orthogonal requirements being satisfied during  
> initialization that should be separated clearly in the design:
> 
> 1) CLOS instance mgmt (such as allocate-instance)
> 2) Elephant instance mgmt (all elephant instances need an OID, a home  
> store, etc)
> 3) CLOS/Elephant slot value initialization
>     a) During creation (all arguments, initforms; write db)
>     b) During deserialization (initforms for transient slots only)
> 4) Slot value access
>     i) For now, always directly to DB
>     ii) maintain indexes
> 
> Every time a persistent object is created or recreated, steps #1 and  
> #2 are required.  #1 and #2 are all tied up in shared-initialize and  
> initialize-instance, and I don't think there is a clean separation  
> between those steps and the steps in #3 that handle the initialization  
> vs. re-initialization problems.
> 
> Additional complications:
> - Schema evolution makes this even more exciting and requires  
> intervention in elephant instance management, slot value  
> initialization and perhaps even slot value access.
> - An additional complication has been dealing with variations among  
> different MOP implementations.
> - We've talked about having a clean way to allow slots to be cached,  
> i.e. to be declared unshared so they only access the DB on writes, or  
> managed which means only written when 'saved'
> 
> Ian
> 
> 
> On Jan 8, 2008, at 7:10 AM, Alex Mizrahi wrote:
> 
> > helo
> >
> > there was a patch that alters the way how objects that are  
> > deserialized are
> > created: it uses allocate-instance and bypasses normal initialization
> > sequence of make-instance.
> >
> > however, there was no documentation given how this is supposed to  
> > work, so i
> > thought this shouldn't affect applications.
> >
> > but we've found that sometimes it has disastrous effects in some  
> > cases.
> >
> > for example, we've found that "strange bug" Robert saw in postmodern  
> > backend
> > happens because initialize-instance of pm-btree is not called.
> >
> > it seems now we should use recreate-instance instead of initialize- 
> > instance,
> > because descendants of "persistent", like btrees and other internal  
> > classes,
> > are completely deprived from normal Common Lisp initialization  
> > functions. if
> > this is intentional, probably it's worth documenting this, because  
> > finding
> > such stuff from weird bugs isn't very pleasant.
> >
> > also, it seems initargs/initforms won't be initialized on recreated
> > instances of persistent, at least i don't see any way how they could  
> > be
> > initialized. we should forget about this functionality for internal
> > elephant's persistent classes?
> >
> > or this damage was not intentional? as i understand, elephant users  
> > are
> > supposed to work with persistent-object, but not persistent class,  
> > so maybe
> > this patch should only affect persistent-object?
> >
> > it's also quite strange that recreate-instance for persistent-object  
> > calls
> > shared-initialize, but for persistent it doesn't. looks like  
> > intentional
> > sabotage! :)
> >
> > but it's not clear how this stuff should affect descendants of
> > persistent-object. if people used initialize-instance :after to  
> > intialize
> > transient slots, how are they supposed to intialize them now?
> > shared-initialize :after? or they should use ele::recreate-instance?
> >
> > with best regards, Alex 'killer_storm' Mizrahi.
> >
> >
> >
> > _______________________________________________
> > elephant-devel site list
> > elephant-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/elephant-devel
> 
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel