[elephant-devel] Class Evolution

[Robert L. Read]

The best way to answer this question would be to look at, or write some
new, tests.

I evolve classes all the time, and have never noticed a problem, at
least if you add
a slot that is not required at object construction time.  Obviously, it
is possible to add
a slot in fact needed for the object to be wholesome, and elephant can't
make something
up in such a case.

In one case I think I actually wrote a little code to:

(map-btree #'(create-and-store a new object of class X) (all-objects of
class Y))

That will always work if you have a class evolution that you just can't
get around
any other way; that is the basic strategy behind inter-store migration.

So I agree with Ben:  it basically works, probably has glitches if you
do something
complicated, but there is, by writing enough (relatively simple) code,
always a way out.



On Thu, 2005-12-29 at 11:52 -0600, Ben wrote:

> it should be relatively class friendly.  it should even support fancy
> stuff like change-class.  there's talk about this in the documentation
> somewhere...
> 
> B
> 
> On 12/29/05, Waldo Rubinstein <waldo at trianet.net> wrote:
> > Is Elephant friendly with class evolution? For example, if I create a
> > CLOS object with, say 5 fields, and store some instances in an
> > elephant DB and then the CLOS definition of the class changes to add
> > a sixth field. What will happen to the existing five objects when
> > retrieved? Will new objects be stored with the new field definition?
> >
> > Thanks,
> > Waldo
> >
> > _______________________________________________
> > elephant-devel site list
> > elephant-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/elephant-devel
> >
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20051230/64c67d21/attachment.html>