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

[Ian Eslick]

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