<!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>
On Sun, 2006-08-13 at 23:27 -0400, Daniel Salama wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
<FONT COLOR="#000000">Robert/team,</FONT><BR>
<FONT COLOR="#000000">I know I've discussed this in the past, but somehow, your comment has awaken my concern as to the future of Elephant and Sleepycat. I know you've mentioned that you are using Elephant mainly (or only) for the relational backend. However, being that the BDB backend is about 5 times faster than the relational one, I was concentrating on using the BDB backend.</FONT><BR>
<FONT COLOR="#000000"> Am I going down the wrong or uncertain path? Will future enhancements to Elephant be focused on the relational backend first? I wish I could say that I can volunteer to help enhance Elephant in anyway, but I just don't have the qualifications; at least not yet. I know there are others involved in the project, but not really familiar with everyone's contributions.</FONT><BR>
</BLOCKQUOTE>
You are not going down a wrong path; you are going down an uncertain path, which has a good contingency plan. The future of BDB itself and its licensing situation is slightly uncertain. If you had to switch to the relational backend, it would be painless; one of the things that Elephant does really well is to allow repository migration (I think.) Elephant insulates you from this consideration, to some extent. BDB is 5 times faster---are you sure that matters to you? One cannot emphasize too much that premature optimization is a bad thing. If someone would just improve the serializer, the relational backend would be much faster --- I know how to do this but have not done so, since, for me, it is irrelevant.<BR>
<BLOCKQUOTE TYPE=CITE>
<BR>
<FONT COLOR="#000000">The one thing I know is that, this, being an open-source project, is sort of like a side task for the current team members. After all, we "all" have to work to put food on the table. So, it's not that I'm asking the dedication of a team of developers such as one assigned by a company offering commercial licenses.</FONT><BR>
</BLOCKQUOTE>
Right. I committed (about a year ago, I think) to maintain it for some time, not necessarily to improve it. By good fortune,<BR>
Ian Eslick has improved it a lot, and I have helped.<BR>
<BLOCKQUOTE TYPE=CITE>
<FONT COLOR="#000000">Through the documents I've read, I think I came across one that said that there are about 15 people (entities) using</FONT><BR>
</BLOCKQUOTE>
That was my guess based on the downloads, questions, and the membership of the lists like this one. It could be <BR>
much, much higher if the average user never asks a question. I honestly wish I know how many people are using it.<BR>
<BLOCKQUOTE TYPE=CITE>
<FONT COLOR="#000000"> Elephant. I don't know if those are just people known to use it and then many others that you just don't know about, or that it really is a low profile project. I can only comment/compare to CL-SQL, which is the other project I've come across more often. I don't use it but do see more traffic related to that project than to Elephant. From what I know, the two projects have different schools of thought and philosophies as to how persistence is implemented and managed. I can say that I like the way things are done in Elephant. They just seem so natural and elegant.</FONT><BR>
</BLOCKQUOTE>
Elephant sits on top of CL-SQL; CL-SQL is the premier database connectivity system for LISP (it rocks.)<BR>
CL-SQL also implements some object mapping stuff (ORM), whereas Elephant implements a straight Object database<BR>
(more or less.) CL-SQL insulates Elephant from changing database issues, and let's us work with Postgres and <BR>
SQLite3, and, with a little work, probably others; its evolution is partially driven by changes in those databases.<BR>
<BLOCKQUOTE TYPE=CITE>
<FONT COLOR="#000000">It is for that reason that I'm concerned with my using of Elephant and BDB backend. I plan to migrate a large project over from Ruby on Rails to the UCW/Elephant framework. I just don't want to shoot myself on the foot down the road when my clients are using the system or, hopefully won't be the case, obsoleted framework.</FONT><BR>
</BLOCKQUOTE>
You will certainly be able to migrate your data to a different backend; although I wish we had more real-world tests of <BR>
this capability, it's definitely there. The real question is: do you really have a performance critical situation?<BR>
I don't plan to work on BDB 4.4 in the next six months, and Ian and I are the only really active developers right now.<BR>
I'm not planning to drop support for BDB either, unless they change the licensing in some way. Perhaps you should<BR>
actually measure your object retrieval rate and see if you think it is acceptable. I personally use DCM (in the contrib dir)<BR>
which is basically an prevalence-style caching system; in general, caching and indexing go a long way.<BR>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
<FONT COLOR="#000000">Thanks again for such great work.</FONT><BR>
</BLOCKQUOTE>
Thanks for using it! I wish I had more time to work on it, but I have children and college tuitions looming...<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
----<BR>
Robert L. Read, PhD read &T robertlread.net<BR>
Consider visiting Progressive Engineering: http://robertlread.net/pe<BR>
In Austin: 912-8593 "Think globally, Act locally." -- RBF<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>