5.3 SQL-Introduction

Although originally designed as an interface to the BerkeleyDB system, the original Elephant system has been experimenetally extended to support the use of relational database management systems as the implementation of the persistent store. This relies on Kevin Rosenberg's CL-SQL interface to relational systems.

Although the BerkeleyDB system is an ideal object store for LISP objects, one might prefer the licensing of a different system. For example, at the time of this writing, it is my interpretation that one cannot use the BerkeleyDB system behind a public website http://www.sleepycat.com/download/licensinginfo.shtml#redistribute unless one releases the entire web application as open source.

Neither the PostGres DBMS nor SQLite 3 has any such restriction. Elephant itself is released under the GPL. It is somewhat debatable if the GPL allows one to construct to construct a non-open-source web application but the preponderance of opinion appears to be that it does. Thefore using Elephant and the other GPLed software that it depends upon allows one to host a a non open-source web application. This might be a reason to use Elephant on PostGres of SQLite rather than Elephant on BerkeleyDB.

Other reasons to use a relational database system might include: familiarity with those systems, the fact that some part of your application needs to use the truly relational aspects of those systems, preference for the tools associated with those systems, etc.

The SQL back-end extention of Elephant provides a function for migrating data seamlessly between repositories. That is, one can quite easily move data from a BerkeleyDB repository to a PostGres repository, and vice versa. In fact, one of the most important aspects of the extention is that it makes Elephant a multi-repository system, rather than a single repository system, as addition to allowing different implementation strategies for those repositories. This offers at least the possiblity than once can develop using one backend, for example BerkeleyDB, and then later move to MySQL.

At the time of this writing, the basic strategy for the SQL implementation is quite simple. The same serializer used for the Sleepycat implementation is employed, the byte-string is base64 encoded, and placed in a single table which is managed by Elephant.

As of Elephant 0.3, Elephant has been tested to work with both Postgres, and SQLite 3, thanks do Dan Knapp.