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"
<[EMAIL PROTECTED]
>
To: "Elephant bugs and development" <elephant-devel@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@common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
