[elephant-devel] QDBM Support

Fri Feb 15 15:01:07 UTC 2008

Thanks for the advice. I agree with you that QDBM support is probably not 
justified at this point.

Regards,
Rangarajan
----- Original Message ----- 
From: "Ian Eslick" <eslick at media.mit.edu>
To: "Elephant bugs and development" <elephant-devel at common-lisp.net>
Sent: Friday, February 15, 2008 7:47 PM
Subject: Re: [elephant-devel] QDBM Support

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