<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2">
</HEAD>
<BODY>
Thank you, your help will be welcome.<BR>
<BR>
My thoughts are on upgrading are:<BR>
<BR>
I think Elephant is getting mature enough and possibly having enough<BR>
users (though I have little hard evidence of this) that we need to start taking<BR>
upgrading very seriously, and ensuring and testing that one can always<BR>
go from a database create with version X to a database created with version<BR>
X+N smoothly.<BR>
<BR>
By "smoothly", I do not mean that you can upgrade with out noticing a change<BR>
or having to do something, but rather that there will be a well-defined process<BR>
that you don't have to be an Elephant hacker to follow to get from X to X+N.<BR>
Probably, this will be automated in most cases, and will be triggered upon <BR>
attempting to make a connection.<BR>
<BR>
This policy allows Elephant to continue to improve in two ways: <BR>
1) We can improve the serializers, which are really efficiency-only improvements<BR>
but none the less very important in terms of performance. The CL-SQL serializer<BR>
in particular is obviously improvable.<BR>
2) We might make a data change which can be computed, but none the less requires<BR>
the user to make a decision. For example, a new indexing method which is usually<BR>
faster but sometimes slower becomes available. The user should make a constant<BR>
decision whether to use the new indexing method or not.<BR>
<BR>
So, under this policy, the act of upgrading will in general take a little human interaction,<BR>
generally in the form of answering some multiple-choice questions, and may require<BR>
a "re-writing" of the database while it is quiescent (that is, off-line) to use a new <BR>
serialization codec or somesuch.<BR>
<BR>
I think the Elephant project should make the promise (P):<BR>
<BR>
P: Any data you now have in an Elephant repository, will be movable somehow, to<BR>
a repository at any higher version number.<BR>
<BR>
I invite discussion of this proposed policy. I don't really know how many people<BR>
out there are using Elephant, and of them how many, if any, are using it in long-lived<BR>
applications with important data. But I know that if we want that to occur in the future,<BR>
we have to act in a manner supportive of it now.<BR>
<BR>
As far as code compatibility is concerned, I think it is acceptable to change the API<BR>
in slight, and documented manners. For example, moving the packaging structure,<BR>
which Ian did, probably breaks some code that uses a previous version and requires<BR>
very minor code tweaks to upgrade to the latest version. I think this is acceptable now<BR>
because: 1) most Elephant users seem to know as much about it as I do :->, and<BR>
2) there are still big improvements (such as Ian's reorganization) that we can make<BR>
if we don't try to fix the API too early.<BR>
<BR>
Certainly, I personally want to use Elephant for long-lived, permanent data and would<BR>
as a user demand promise P of a system like Elephant.<BR>
<BR>
On Fri, 2006-03-03 at 21:38 +0200, Evrim ULU wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
<TT><FONT COLOR="#000000">Dear Robert,</FONT></TT><BR>
<BR>
<TT><FONT COLOR="#000000">I've dropped most of the btrees from my code so, it won't be a problem</FONT></TT><BR>
<TT><FONT COLOR="#000000">next-time but i am curious if it will happen again or not. If you can</FONT></TT><BR>
<TT><FONT COLOR="#000000">state your thoughts about upgrading, it'll be great.</FONT></TT><BR>
<BR>
<TT><FONT COLOR="#000000">Btw, i've tried to solve the problem for a week but unfortunately it</FONT></TT><BR>
<TT><FONT COLOR="#000000">seems i'm not familiar with elephant yet. I hope, in time, i'll know </FONT></TT><BR>
<TT><FONT COLOR="#000000">better and help you to develop it.</FONT></TT>
</BLOCKQUOTE>
</BODY>
</HTML>