[elephant-devel] Incompatibilities between different versions

[Robert L. Read]

Thank you, your help will be welcome.

My thoughts are on upgrading are:

I think Elephant is getting mature enough and possibly having enough
users (though I have little hard evidence of this) that we need to start
taking
upgrading very seriously, and ensuring and testing that one can always
go from a database create with version X to a database created with
version
X+N smoothly.

By "smoothly", I do not mean that you can upgrade with out noticing a
change
or having to do something, but rather that there will be a well-defined
process
that you don't have to be an Elephant hacker to follow to get from X to
X+N.
Probably, this will be automated in most cases, and will be triggered
upon 
attempting to make a connection.

This policy allows Elephant to continue to improve in two ways: 
1) We can improve the serializers, which are really efficiency-only
improvements
but none the less very important in terms of performance.  The CL-SQL
serializer
in particular is obviously improvable.
2) We might make a data change which can be computed, but none the less
requires
the user to make a decision.  For example, a new indexing method which
is usually
faster but sometimes slower becomes available.  The user should make a
constant
decision whether to use the new indexing method or not.

So, under this policy, the act of upgrading will in general take a
little human interaction,
generally in the form of answering some multiple-choice questions, and
may require
a "re-writing" of the database while it is quiescent (that is, off-line)
to use a new 
serialization codec or somesuch.

I think the Elephant project should make the promise (P):

P: Any data you now have in an Elephant repository, will be movable
somehow, to
a repository at any higher version number.

I invite discussion of this proposed policy.  I don't really know how
many people
out there are using Elephant, and of them how many, if any, are using it
in long-lived
applications with important data.  But I know that if we want that to
occur in the future,
we have to act in a manner supportive of it now.

As far as code compatibility is concerned, I think it is acceptable to
change the API
in slight, and documented manners.  For example, moving the packaging
structure,
which Ian did, probably breaks some code that uses a previous version
and requires
very minor code tweaks to upgrade to the latest version.  I think this
is acceptable now
because:  1) most Elephant users seem to know as much about it as I
do :->, and
2) there are still big improvements (such as Ian's reorganization) that
we can make
if we don't try to fix the API too early.

Certainly, I personally want to use Elephant for long-lived, permanent
data and would
as a user demand promise P of a system like Elephant.

On Fri, 2006-03-03 at 21:38 +0200, Evrim ULU wrote:

> Dear Robert,
> 
> I've dropped most of the btrees from my code so, it won't be a problem
> next-time but i am curious if it will happen again or not. If you can
> state your thoughts about upgrading, it'll be great.
> 
> Btw, i've tried to solve the problem for a week but unfortunately it
> seems i'm not familiar with elephant yet. I hope, in time, i'll know 
> better and help you to develop it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20060303/e9115a12/attachment.html>