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