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

[Sean Ross]

On Jan 8, 2008 3:31 PM, Ian Eslick <eslick at csail.mit.edu> wrote:
> Actually I think we definitely need to fix this.  Quite a few people
> have run into the problem that we're violating the CLOS contract on
> make-instance and that we should not use the same CLOS calling path
> for re-initialization that we use for initial creation.  I think we
> should require new contracts rather than messing with familiar ones.
>
> One proposal was to create a placeholder class and then call change-
> class on it, but that still evokes the initargs for new slots and
> creates problems of its own.  Another one is to make a cheap
> placeholder that is only initialized when touched, which I like but
> can't think of how to implement.
>
> As the next step, I think we probably want to figure out, for
> deserialized instances, how to create a minimal instance, initializing
> transient slots only, handle any schema evolution we choose to
> implement and then call a generic function (reconstitute-instance)
> that users can define methods on to do any deserialization time
> specialization.  This way the users can do the usual 'on creation'
> specialization on initialize-instance without having it called
> multiple times in unexpected ways.

Hi all,

I've been giving this some thought and without investigating how much
work this would take
I see the loading of persistent instances working something like this.

We (actually in this case i only speak for myself) want something which,

a) Allow customization of both instance creation and instance deserialization.
b) fits in well with the current initialization & reinitialization protocols.
c) Is relatively (for some value of relatively) non obtrusive.

With that in mind I would propose something like the following.

Deserializing instances is done using recreate-instance. This method
allocates a new instance of the class using allocate-instance and
passes this to reconstitute-instance which falls through to
shared-initialize which does all the dirty work.

(recreate-instance (persistent-metaclass))
  -> (allocate-instance (standard-class) &rest &key)
  -> (reconstitute-instance (persistent-object) &rest &key)
      -> (shared-initialize (persistent-object) t &rest &key)

This should satisfy everyones requirements, allowing specialization of
methods for instance deserilazation, instance creation or both using
initialize-instance, reconstitute-instance and shared-initialize
respectively.

This would also make it relatively easy to add in schema evolution by
adding a :before method on
reconstitute instance.
The only drawback that is immediately apparent to me is that this can
break backwards compatibility since there may be specialized methods
on initialize-instance that will no longer be called, although this
can be easily worked around by specializing on shared-initialize or
altering reconstitute-instance  to call initialize-instance.

comments?

cheers,
 sean.