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" <[EMAIL PROTECTED]> > To: "Elephant bugs and development" <elephant-devel@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" <[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 > > > _______________________________________________ > 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
