[elephant-devel] Status of Leslie's question and Sean's patch?

[Ian Eslick]

Leslie,

Please correct me if I'm wrong, but isn't this exactly what Lisp  
does?  If you assign the wrong type to a slot under SBCL, it doesn't  
complain so in this sense Elephant behaves in the same way as Lisp  
does with in-memory objects.  At some point it is our responsibility  
not to shoot ourselves in the foot!

The only reason I'm resistant is having spent some time looking at  
related problems.  There is a big discussion in the list archives  
(mostly one sided from me) of ways to handle schema evolution, the  
more general version of the problem you point out with slot type  
mismatches.  I would like to improve the default behavior and error  
handling of these cases, but the interaction between MOP functions  
such as update-instance-for-redefined-class method and persistent  
instances is pretty complicated.  For example, if you don't map all  
instances of an object after class redefinition, then some objects are  
in-line with an old schema, and some with the new.  That's not a  
problem if the update method is called on class initialization, but  
there is no guarantee from lisp that this will happen because you  
could exit and restart before you've loaded every instance.

Even if you don't exist, what if you redefine the class yet again?   
Then there are serialized objects in the store that were written under  
three different schemas and no way to ensure you can update the two  
old ones to the new one correctly as you only have one update-instance- 
for-redefined-class method for a given class.  If it isn't called on  
every instance after every redefinition, then it can result in  
inconsistencies.  The only way to ensure this doesn't happen that I  
can think of is to make sure that every instance effected by the  
redefinition is properly updated at redefinition time.  Lazy  
redefinition can't be guaranteed to be consistent.

I'm very open to suggestions (although I'm unlikely to implement this  
feature anytime soon).  There has been alot of discussion around this  
area (see Pierre and I discussing class deserialization and  
initialization, part of which should be solved by Sean's patch) that  
the initialization and reinitialization on deserialization protocol  
should probably be rethought.

Cheers,
Ian

PS - Anyone know how lisp handles multiple redefinitions under the  
usual lazy update-on-read policy?





On Dec 21, 2007, at 8:03 AM, Leslie P. Polzer wrote:

>
> Hi Ian,
>
> thanks for making it clear. Of course, I guessed this and the  
> Elephant code
> I looked at didn't say otherwise, but you're knowledge is obviously  
> greater.
>
>> The right user approach is to provide a function to walk over
>> instances and update their representation or zero them out.  Other
>> than an assertion on deserialization or a general warning on type
>> change, I can't think of a really useful default policy.
>
> I can, sort of: Elephant should offer an easily usable facility
> to specify what should happen when the types don't match, something  
> like
>
> (defmethod elephant:convert-slot ((from pic) (to string)))
>
> which is pretty much exactly what convert-class is for, so we might  
> just use this.
> Wouldn't it suffice to just do
>
> START) type changed? [this decision should be based on the :type  
> slot-initarg]
>   Yes: call convert-class
>    No: simple assignment
>
>
>> Have you tried this and seen what happens?
>
> Neither warning nor error, just assignment of the old data.
>
>
>> What Lisp are you using?
>
> I'm using SBCL/Linux/x86.
>
> This functionality is important IMHO; without it, sensible Lisp- 
> style Rapid Prototyping
> is hardly possible when one needs to call map-root everytime  
> something changes.
>
>  Leslie
>
> -- 
> My personal blog: http://blog.viridian-project.de/
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel