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

Alex Mizrahi killerstorm at newmail.ru
Tue Jan 8 12:10:17 UTC 2008


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. 






More information about the elephant-devel mailing list