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

[Ian Eslick]

On Apr 27, 2007, at 6:36 PM, Pierre THIERRY wrote:

> Scribit Ian Eslick dies 27/04/2007 hora 15:37:
>> The persistent slots of that class have the allocation parameter
>> :database instead of :instance to capture these semantics.
>
> Should'nt that be orthogonal? Currently, that means persistent class
> allocated slots are not supported. I never had to use them, though,  
> so I
> didn't think much about their usefulness...

That is correct, we don't store class objects of any kind at this  
point either.

>> You might read metaclasses.lisp and classes.lisp if you want a deeper
>> understanding of how this works.
>
> Yes, I only gave them a superficial look before, only to add some  
> locks
> around slot access (which was surprisingly easy, and though it  
> might not
> have been very clean, it was working for me...).

Actually at this point you shouldn't need to put locks around slot  
access.  All slot operations are transactional at the data store  
level even when they're not in a formal transaction so thread safety  
should come for free.  (Unless you've caught some shared access in  
the slot protocol that I've missed).

>> 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.
>
> That's making a placeholder instance, not making a persistent class
> instance, semantically.

That would explain some of the confusion!  The placeholder instance  
(according to your definition) in Elephant is an instance of  
persistent-metaclass and inherits from persistent-object, so it is a  
persistent-metaclass instance, strictly speaking.

I'd be curious what a persistent class instance would look like by  
your semantic definition.  Do you mean an object that has its slot  
values in memory rather than in the database?  (like prevalence  
objects?)


>> 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?
>
> Because you're not creating an instance of it, you're creating storage
> to hold an already created instance of it.

Or perhaps it's the awkward semantic use of the MOP API you are  
bothered by, not the low-level dynamics of storage management that it  
executes?

>> I'm open to a better solution to handling slot  initialization in the
>> fresh vs. reconstituted cases.
>
> I'll think on it. It's very pleasant to know a proposal will be  
> welcome.

Of course I can't guarantee to make the change in any particular  
timeframe.  If you really want to clean this up the best way is to go  
in and do it yourself!

I've cleaned up quite a bit of the internal design and API since I  
started working on Elephant because it impinged on what I wanted to  
do in my own projects, the initialization isn't something I'm  
terribly concerned about as it hasn't bothered me much.  I have a  
mile long list of issues like this I've discovered while updating all  
the code Robert and I inherited.  (I think I just logged Trac ticket  
#50 today).

Speaking of Trac, this would be a great issue to document in a Trac  
ticket or on the wiki, you should be able to submit them as an  
anonymous user now.  If you have a common-lisp.net account you should  
have a Trac password and can login and edit the wiki or submit Trac  
tickets under your own common-lisp.net uid.

> 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/2ecffbf2/attachment.sig>