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