[elephant-devel] QDBM Support

Fri Feb 15 14:17:46 UTC 2008

For now, SQLite3 is the best way to avoid royalties and have an easily  
deployable solution.  As Alex said, given the way we are using the SQL  
engine to store data, the performance isn't so great compared to BDB  
because we're simulating BTrees on top of SQL.  If you want a direct  
map to a SQL DB, you're better off using CL-SQL directly (the query  
system is probably richer, but I find it more of a pain to manage,  
particularly the schema evolution.

If QDBM supported Ming on Windows, I'd be happy to port it, but unless  
the solution works on all platforms I'm less motivated.

Ian

On Feb 14, 2008, at 2:16 AM, Rangarajan Krishnamoorthy wrote:

> Thanks for the detailed suggestions.
>
> I haven't thought about Postgres, but your suggestion sounds good.  
> Does Postgres require any admin-type task by end users of my  
> application? I hope not, because my intended audience is medical  
> Doctors!
>
> I am in contact with Oracle India regarding the license and they  
> have confirmed that I have to pay royalties. Although the royalty  
> appears quite reasonable, looks like I have to be an "Oracle  
> Partner" to distribute BDB under this licensing clause. There is an  
> annual fee to be an OPN, which equals about 100 license royalty  
> payments per year!
>
> Before I bought LispWorks I was keen to use Allegro CL/Allegro  
> Cache, but found that the royalties there are astronomical, so  
> decided to switch loyalty to LW. Let us see how this goes.
>
> For a product that cannot cost more than $500, and might not sell in  
> huge numbers, this seems like too much trouble!
>
> Thanks for your advice.
> Regards,
> Rangarajan
> ----- Original Message ----- From: "Robert L. Read" <read at robertlread.net 
> >
> To: "Elephant bugs and development" <elephant-devel at common-lisp.net>
> Sent: Thursday, February 14, 2008 11:01 AM
> Subject: Re: [elephant-devel] QDBM Support
>
>
>> On Thu, 2008-02-14 at 10:35 +0530, Rangarajan Krishnamoorthy wrote:
>>> Robert,
>>> I am the one who started this thread, so let me clarify.
>>>
>>> The background: I am starting to work on a .NET-based application  
>>> (for
>>> Windows platforms) that might benefit by Lisp integration. I  
>>> purchased
>>> Lispworks Enterprise in this context. When I searched for a lisp  
>>> persistence
>>> library, I was told to consider Elephant. I tried it and it seems  
>>> to work
>>> fine for me. Elephant documentation advises that BDB is the best  
>>> performing
>>> backend among the backends it supports. But it appears that I  
>>> cannot just
>>> "buy" BDB by opting for a one-time initial payment. I have to pay  
>>> runtime
>>> royalties. This is different from other libraries that I have used  
>>> so far.
>>> Although there may be legitimate reasons why Oracle does it this  
>>> way, I am
>>> more comfortable with one-time payment. So the problem I am facing  
>>> is that I
>>> would love to use Elephant in my work, but BDB's licensing is the  
>>> concern. I
>>> found out that QDBM is another popular DB implementation which  
>>> does not have
>>> this licensing issue, so posted the question to this list. It is  
>>> not just
>>> that QDBM outperforms BDB (I don't know this). Please note that I  
>>> am not
>>> against paying for the library that I use, but just that I am not  
>>> in favor
>>> of royalties.
>>
>> Thanks for the clarification --- I got tangled in the thread.
>>
>> However, this allows me to rephrase my question:  Can you consider  
>> using
>> the postmodern backend (which is an interface to the PostGres  
>> database)?
>>
>> PostGres is free.  The Postmodern backend is probably 3 to 10 times
>> slower than BDB, and might be even worse in some circumstances.
>> However, it is entirely possible that 10 times very fast is still  
>> fast
>> enough for whatever operation you intend.
>>
>> It is unfortunate that to test this you will have to install PostGres
>> and do a very, very small amount of db administration on PostGres in
>> order to execute Elephant against it.  With experience this should  
>> only
>> take a few hours.
>>
>> I share your attitude toward royalties in this matter, which is  
>> mainly
>> the reason I wrote the CL-SQL-based backend.
>>
>> I know only what you have stated about your application, but one
>> possibility, if you have no better alternative to Elephant, is to use
>> the postmodern backend now, during your development, and be  
>> prepared to
>> either switch to BDB by paying for it later, or to hope for (and  
>> perhaps
>> help) an effort to either implement QDBM or a LISP-native backend.
>>
>> Allow me to ask if you have really carefully considered the BDB  
>> license:
>>
>> http://www.oracle.com/technology/software/products/berkeley-db/htdocs/oslicense.html
>>
>> ...and concluded that you would have to pay a runtime royalty for  
>> your
>> specific application?
>>
>> (As an aside:  I have not studied the other persistence solutions
>> deeply.  I suspect that using CL-SQL directly (not through  
>> Elephant) is
>> one of the most common and well-tested mechanisms.  This is an
>> Object-Relational Mapper (ORM) similar to Hibernate or Ibatis  
>> (although
>> a bit less evolved, I think.)  This approach would require you to  
>> do a
>> great deal more work than Elephant does, since you have to create  
>> tables
>> and consciously map your classes into those tables and be prepared to
>> deal with schema evolution when you change the design of your object
>> space.  I think Elephant is much more convenient, but using CL-SQL
>> directly is an option.)
>>
>>
>>
>>
>>
>>
>>>
>>> Coming to your suggestion that it would be wise to build a very  
>>> simple,
>>> native lisp backend without the "frills", I am for it!
>>>
>>> Regards,
>>> Rangarajan
>>>
>>> ----- Original Message ----- From: "Robert L. Read" <read at robertlread.net 
>>> >
>>> To: "Elephant bugs and development" <elephant-devel at common-lisp.net>
>>> Sent: Thursday, February 14, 2008 9:38 AM
>>> Subject: Re: [elephant-devel] QDBM Support
>>>
>>>
>>> > On Wed, 2008-02-13 at 10:41 -0500, Ian Eslick wrote:
>>> >> The answer to all of this, I think, is having a native lisp  
>>> version
>>> >> that has BDB's performance and no licensing restrictions.  Then
>>> >> supporting the other two becomes: Postmodern for a higher  
>>> degree of
>>> >> reliability as well as for distributed systems and BDB for legacy
>>> >> reasons.
>>> >>
>>> >> I have a pretty good idea in my head of what an all-lisp backend
>>> >> requires and having one would lay to rest all of these  
>>> discussions
>>> >> of
>>> >> bringing up "yet another backend".  Edi Weitz and I discussed
>>> >> collaborating on this, but unfortunately he had some other  
>>> projects
>>> >> that took priority.
>>> >>
>>> >> Is there a small critical mass of people out there that care  
>>> enough
>>> >> about this that they'd be willing to contribute to such a  
>>> project?
>>> >> I
>>> >> don't have the time to do it on my own, but if we broke it up  
>>> into
>>> >> small projects over the next handful of months, I don't think  
>>> it's a
>>> >> ton of work.  I can put in a solid chunk of integration work in  
>>> mid
>>> >> to
>>> >> late April.
>>> >>
>>> >
>>> > I completely agree with Ian about the value of a LISP-native  
>>> backend.
>>> >
>>> > However, I can not personally offer to help with this.  I have  
>>> in fact
>>> > abandoned my business plans for the time being and taken a  
>>> normal job.
>>> > Moreover, since I did the "schema evolution" system that we used  
>>> in the
>>> > Java application for Hire.com a while back, I feel more  
>>> comfortable
>>> > working on that than on the LISP native backend, although I  
>>> think both
>>> > are wonderful and challenging problems.
>>> >
>>> > The excellent set of automated tests produced by the original  
>>> authors > of
>>> > Elephant (Andrew Blumberg and Ben Lee) and strengthened by Ian and
>>> > myself and others since then remain the greatest asset in  
>>> undertaking
>>> > the LISP-Native backend.
>>> >
>>> > I know that many of you understand most of the technical  
>>> challenges in
>>> > bringing up a Native LISP backend better than I do.  However,  
>>> let me > ask
>>> > the question that my acquaintance Kent Beck always asks:
>>> >
>>> > What is the simplest thing that could possible work?
>>> >
>>> > By which I mean, is there any value in making a very simple LISP  
>>> native
>>> > backend?  Forget locking, transactions, efficiency, and all that  
>>> other
>>> > ocean-boiling stuff that we all know will be needed for an  
>>> enterprise
>>> > application.  Can anybody build a Native-Lisp backend in a  
>>> weekend?
>>> >
>>> > If so, we would have an excellent "spike" solution that would  
>>> inform
>>> > further efforts, and furthermore we would have an out-of-the-box
>>> > solution for demoing Elephant that would require ZERO additional
>>> > software installations.  This would be very useful, even if  
>>> there are
>>> > performance and reliability limits to that backend.
>>> >
>>> >
>>> > _______________________________________________
>>> > elephant-devel site list
>>> > elephant-devel at common-lisp.net
>>> > http://common-lisp.net/mailman/listinfo/elephant-devel
>>>
>>>
>>> _______________________________________________
>>> elephant-devel site list
>>> elephant-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel