[elephant-devel] Re: blog example w/ hunchentoot

[Ian Eslick]

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 like
> deserialize-instance (which I'll call d-i for short), and be a  
> member of
> the 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,  
> with
> slots 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 it
has 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- 
> instance
> would 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 storage
for 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-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.
>
> 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
> -- 
> nowhere.man at levallois.eu.org
> OpenPGP 0xD9D50D8A
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20070427/e39541cc/attachment.sig>