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@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
