[elephant-devel] QDBM Support

Fri Feb 15 01:54:46 UTC 2008

In order to deploy with Postgres you will have to write a script to 
create the db with the correct name.  That is all that you will have to
do, in order to have a system that technically runs.

There may be long-term administrative tasks, such as executing "vacuum"
to clean up indexes on a periodic basis.  You might be able to code this
into your application.  I don't think it would ever keep something from
working, but it might slow things down after months of use.

I can see now that a Native-LISP backend would really be a blessing for
your intended usage.

Postgres has some installation set up which is required; you will have
to work out a way to script this if you are selling it as an embedded
database.

It is possible that SQLite3 might even be better for you; I am not
terribly familiar with it.  I know that is is much simpler than PostGres
and faster, though less "industrial" in its feature set.

On Thu, 2008-02-14 at 12:46 +0530, 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