Next: Postmodern Data Store, Previous: Berkeley DB Data Store, Up: User Guide
Elephant uses Kevin Rosenberg's excellent CLSQL CLSQL lisp binding to relational databases (it does not use the ORM functionality offered by that package.) CLSQL interfaces to many databases (Postgres, MySQL, Oracle, ODBC, SQLite3, Microsoft SQL Server (via ODBC)). Right now, Elephant has been tested with Postgress and SQLite3. Probably getting it to work with one of the others will take a small amount of debugging; in principle there is no reason it won't work out of the box. We invite users to try other database, and will quickly incorporate patches needed to make them work.
Because CLSQL is very generic, the CLSQL interface does not offer any special feature as discussed in the previous section Berkeley DB Data Store.
The CLSQL uses base64 encoding to store binary data as text directly. This has the advantage that it works with all databases, which tend to differ widely in their treatment of Binary Large Objects (BLOBs.) It imposes some obvious overhead.
The CLSQL implementation is structurally exactly the same as the BDB implementation. A single table is created to hold all (key,value) pairs. An index on the key column provides efficient key lookup. No additional indexing offered by the underlying databases is used. This has the advantage that the API is exactly the same as the BDB api, and all of the functional indexes, cursors, and secondary indexes work exactly the same way. It does not exploit the performance that a database-specific solution would offer (see Postmodern Data Store for an example of such a system.
Our basic strategy is to leave the CLSQL interface as simple as possible, in order to work with as many databases as possible. When there is enough motivation to support a backend that is specific to one database (and therefore probably faster), such an interface can be placed into the “contrib” directory and migrated into the main code base as time allows the complete integration with the test suite.