Think of it this way. If you get a value from a persistent index and that value is a persistent object, then you want object identity, the ability to inspect it's type, slot access, etc. The only way to do that is to create something in memory which provides this. The only way to that is to make sure your lisp has had the chance to construct everything it needs via make-instance.
The :from-oid argument to make-instance overrides some of the normal make-instance behavior by inhibiting all initform initialization as the object's slots are assumed to already be valid, so you have exactly the behavior you want.
There are two caveats to this nice model: transient slots and make- instance methods.
Transient Slots: they have the semantics of ordinary lisp slots - you cannot expect them to persist between images or after their placeholder has been garbage collected. If you drop all references to an object with transient slots, those slots are reclaimed by the GC. If you try to access them again later, they are reset to their default state (unbound, initforms or make-instance computations).
Make-instance specializers: If you override the typical make-instance via :before, :after, :around or specialized on your class, you have to make sure that you predicate on :from-oid (this will be documented in the new manual) to avoid resetting persistent values. If :from- oid is given a value, then you can assume the object is being reconstituted and you don't need to do anything special for the persistent slots.
However, if you want to use persistent slots to compute the value of some transient slots, then a make-instance specializer is a good place to do it. indexed-btree is an example of this, an in-memory hash is cached in the transient slot for reads and writes are mirrored to a serialized hash in a persistent slot.
Ian On Apr 23, 2007, at 6:42 PM, Pierre THIERRY wrote:
Scribit Ian Eslick dies 22/04/2007 hora 10:39:However, if the objects are not already in-memory, the deserializer will call make-instance on that instance using the OID and class stored in the DB. This does not call initforms or use initargs but will trigger any initialize-instance method specializers you have defined (such as after methods).Would it be possible to deserialize the objects without triggering all this initialization? There's a semantic issue, here, because an image using persistent objects should behave the same with or without beingshut down and restarted. This is precisely a goal of persistence, in theway I understand it.If initialization is triggered, you have a visible behaviour change whenthe Lisp image is shut down and restarted. Do you think it would be reasonable to get rid of that? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
