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

[Ian Eslick]

persistent is simply a base class that maintains an OID which is  
initialized using the :from-oid (so it picks up the oid during  
deserialization by default)

persistent-object is the superclass for all objects for which we are  
allowing the persistent slot access protocol

persistent-collection is essentially a placeholder.  Persistent  
collection objects do not have persistent slots, but act as types to  
specialize gf's like get-value.  persistent-collection inherits oid  
and the :from-oid initarg from persistent.


Cool!  I apologize that I really don't have time to fully think  
through your code just now so I might get some of this wrong as it's  
mostly off the top of my head, however it seems like you've got the  
right idea.

1) The call to shared-initialize (and the :around method on persistent- 
object) could cause some of the problems people have reported.  For  
example, if I make a slot unbound on an instance, when it is reloaded,  
shared-initialize will evaluate the default form and rebind it to that  
value.  If the initform is at all interesting, rather than a default  
value, then that function can get called more than once leading to  
potentially unexpected side-effects.

FIX?: If you call shared-initialize with the slotnames returned by  
(transient-slot-names class) this might avoid those problems and  
handle the transient slot init all in one go.

2) This code seems to bypass initialize-instance :before which sets up  
the connection to the home store controller and I think is responsible  
for setting the oid.   but then we've called the :around function on  
persistent-objects which calls instance initialization for all the  
slots.

FIX: We should factor out this functionality into a helper function  
called 'associate-persistent-object' (or perhaps this what you  
intended by initial-persistence-setup?  You didn't provide a  
definition for it) and put a call to the helper function in initialize- 
instance :before as well as after the allocate-instance call in  
recreate-instance-using-class

The functions for persistent-objects are:
- initialize-instance :before
	sets up the OIDs and store-controller link for the instance
	called in both cases
	has to be called prior to shared-initialize :around in the creation  
case
- shared-initialize :around
	initializes both persistent and transient slot values
	should be called only during creation
	PROBLEM: I think the standard shared-initialize needs to be called
                  during deserialization too?
- update-instance-for-redefined-class
	called by CLOS; should be OK, but isn't applied properly to all db  
instances
	so needs some schema-evolution support
- change-class / update-instance-for-different-class
	FIX!  This should be specialized on persistent-object, not persistent  
I think
	Does it make any sense today to change the class of a btree?  Perhaps  
we should
	keep it as it is and catch the cases where a user tries this on a  
persistent-collection
- slot protocol
	relies on the oid/controller being set, but should be good until we get
         into slot value caching

I guess this wasn't as hard as I thought!

Ian

On Jan 8, 2008, at 2:31 PM, Alex Mizrahi wrote:

> SR> I'm sorry to hear that my patch caused so many issues with  
> postmodern
> SR> and I'm quite keen to investigate the cause of this. I'll be
> SR> installing setting up the postmodern backend and seeing if I can  
> track
> SR> down the causes of these problems.
>
> looks like it's related to some deep weirdness of db-postmodern
> implementation, and i think i've almost tracked this down, so i don't
> recommend anyone spending time on this. (well, until/if i'll give  
> up..)
>
> however i'd like to see comments about class "persistent" -- it  
> doesn't even
> recieve shared-initialize, are there any reasons for special  
> threating of
> it?
>
> and are there reasons for using this recreate initialization  
> sequence for
> class "persistent"?
>
> only instances of classes of persistent-metaclass metaclass (e.g.
> persistent-object) can have persistent slots, so it makes sense to  
> bypass
> make-instance only for such classes.
> other classes have quite
>
> SR> As to where to go from here I do agree with robert on this and  
> that it
> SR> is nice to have the seperation between the creation and  
> restoration of
> SR> instances although I think this needs to be done with a well  
> thought
> SR> out protocol.
>
> SR> cheers,
> SR>  sean.
>
> )
> (With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
> "Hanging In The Balance Of Deceit And Blasphemy")
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel