[elephant-devel] QDBM Support

[Robert L. Read]

On Wed, 2008-02-13 at 16:06 -0500, Ian Eslick wrote:
> Re: Tokyo Cabinet
> 
> The API is nearly identical to BDB's.  I think a TC version of the  
> datastore would be pretty easy to do.  The only way it makes sense
> to  
> me to do this is to deprecate the BDB data store as of the next
> major  
> release.   Any thoughts on this?

I would ask the original poster if we have strong reason to believe BDB
is not fast for his original purposes.  I certainly don't mind
considering implementing QDBM, but if a particular user wants that
before they have shown that BDB is not fast enough for their purposes,
it seems to me that this is a form of "gold-plating".  I personally
would rather work on clean schema evolution than a QDBM backend; but if
someone else wants to do the work I will support it.

> 
> Depreciation:
> 
> Speaking of which, what is the thinking on the CL-SQL store?  With  
> postmodern, there is a SQL interface - do we want to maintain CL-SQL  
> long term?  It does cover more SQL backends, including the
> easy-to-use  
> SQLite, but it's another fork to maintain.  I'm agnostic, but I  
> thought I'd toss that out for Robert to comment on.
> 

I think the CL-SQL is worth preserving at present for three reasons.
The SQLite support is the first; secondly fact that it has helped find
bugs in the postmodern backend (though only as a reference
implementation), and finally the fact that it is the shortest path to
MySQL, Oracle, or SQLServer integration.  That is, if someone wanted to
run Elephant or Oracle, or more likely MySQL, in just a few days they
could get the CL-SQL backend to do that.  It would of course have the
problems that Henrik and Alex improved upon in the postmodern backend,
and which Ian has written about, which are basically that it is slow and
might be very slow in some usage patterns.

I think the time to deprecate the CL-SQL backend might come when we
actually implement a feature which it makes harder to support.  For
example, a LISP-Native backend is orthogonal to the CL-SQL backend, but
implementing a more abstract "Set/Ordered Set" model as we have
discussed might not be.  So as soon as it actually becomes a pain to
support it, we can consider it.  (I would love to know who is using
SQLite 3 right now, or even how many total users we have at all.)