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@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
