I'm not sure I followed all this. To restate...A persistent object (in Elephant) is one who's slot values are stored on disk, not in memory. The persistent slots of that class have the allocation parameter
:database instead of :instance to capture these semantics.
That means that any persistent object that resides in memory serves as an access proxy for the slot values stored on disk (what I refer to as a placeholder instance). Currently every persistent slot access goes directly to the database (which may cache slot values in memory or not). The oid parameter and store- controller parameter is what dispatches a slot-value request on the in-memory instance to the actual database
slot value.The persistent protocol specializes initialize-instance and shared- initialize on persistent-metaclass and uses the :from-oid parameter to distinguish between fresh proxy instances and reconstituted proxy instances and adjusts the slot initialization policy appropriately so it does not re-initialize persistent values in the latter case.
I think what you are getting at is that the persistent metaclass protocol should have a cleaner way of separating the initial slot initialization from the recreation of an existing instance other than relying on :from-oid. I don't disagree with this, but am unsure how to implement it given the commitments of the current protocol. Moreover, you still have to allocate storage and initialize transient slot values so this approach
isn't really that wasteful or messy.However if you're interested in finding a better solution, the metaclass protocol implementation could be done much cleaner so after 0.9 is released, you are welcome to take a crack at it. I've had higher priorities than code cleanup, although I hope
to do some more prior to 1.0. I have a few more comments below. On Apr 27, 2007, at 2:34 PM, Pierre THIERRY wrote:
Scribit Ian Eslick dies 23/04/2007 hora 18:55:I'm not sure that deserializing a persistent object without actually creating it would make much sense. What would you return from the deserializer? What operations would it need to support?I tend to think that deserialization should be something likedeserialize-instance (which I'll call d-i for short), and be a member ofthe family of GFs whose system-supplied primary method calls shared-initialize, viz. initialize-instance, reinitialize-instance, update-instance-for-redefined-class, and update-instance-for-different-class.d-i should be a function with side-effects, that may take a placeholder instance and move it to an instance of the proper persistent class, withslots filled with either their transient value, their persistent value or a placeholder instance for the latter.
I think we are using the placeholder instance terminology differently.The placeholder instance IS the persistent class instance. Its persistent
slots are always valid so change-class wouldn't need to be called. The persistent class instance is just like a standard class, except that ithas a set of persistent slots that act as a proxies between the lisp program
and the database for access to their slot values.The Elephant persistence model is very different than the one you may have encountered if you are familiar with prevalence style databases where the
persistent values actually are moved into memory from disk. You might read metaclasses.lisp and classes.lisp if you want a deeper understanding of how this works.
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.I'm not sure make-instance should be called here. reinitialize- instancewould be a far better choice.
You can't call reinitialize instance unless you have an instance to reinitialize. When you are deserializing a persistent object reference and the object isn't in memory, you need to create storagefor at least the oid and store-controller reference. If you are creating an object, why not create one using the class of the one you are going to
use rather than invoking more generic function overhead to copy values around?
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.Make-instance specializers: If you override the typical make-instancevia :before, :after, :around or specialized on your class, you have tomake sure that you predicate on :from-oid (this will be documented in the new manual) to avoid resetting persistent values.Well, according to the spec, users should better define methods on make-instance, but on shared-initialize or initialize-instance.
True, the above statement holds for shared-initialize and initialize- instance as well. I'm open to a better solution to handling slot initialization in
the fresh vs. reconstituted cases.
Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A _______________________________________________ elephant-devel site list [email protected] http://common-lisp.net/mailman/listinfo/elephant-devel
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ elephant-devel site list [email protected] http://common-lisp.net/mailman/listinfo/elephant-devel
