IE>>> our learning. My guess is that getting all this right can best be
IE>>> accomplished by rationally designing all the functionality from
IE>>> scratch, and rewrite the persistence protocol as necessary to
IE>>> accommodate the new design.
??>>
??>> the way it was working before "the patches" seemed to be more-or-less
??>> consistent to me.
??>> at least it wasn't that confusing..
IE> I think the problem is that initialize-instance gets called each time,
IE> so if you define an :after method on it for object creation time - for
IE> example that computes a specific slot value, then that code gets rerun
IE> on object re-initialization and clobbers any updates that happened in
IE> the meantime.
what's wrong with having such structure of initialize-instance:
(defmethod initialize-instance :after ((instance some-class) &rest initargs
&allow-other-keys)
(unless (member :from-oid initargs)
;; modify persistent slots for the first time
)
;; do "transient" initialization here
)
?
IE> Actually this would happen as expected. Objects loaded into memory
IE> would automatically get the initforms of the transient fields, unless
IE> they wanted to override the default by calling the special generic
IE> function.
i thought people might be doing all sorts of funny stuff in their
initialize-instances -- additional initialization unrelated to instance
slots, validation, writing to logs etc.
and they can be surprised that once they make class elephant-persistent and
it's loaded from DB, their stuff is not executed anymore.
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
