Next: , Previous: Extention Status, Up: SQL back-end


5.3 Back-compatibility

The CL-SQL based extention is very back-compatible with any existing Elephant application, except for two items.

First, the routines “build-btree” and “build-index-btree” should be used in place of the previous approach to direct calls to make-instance. This is necessary, because the underlying class of the object depends on what repository it is stored in. These routines, like make-instance on persistent objects directly, allow you to specify the store controller at creation time. However, build-btree and build-index-btree will use the global *store-controller* if no keyword argument is provided.

Secondly, in addition to executing:

     (asdf:operate 'asdf:load-op :elephant)

to load elephant, one must at least one of:

     (asdf:operate 'asdf:load-op :ele-clsql)
     (asdf:operate 'asdf:load-op :ele-bdb)

To use SQLLite3, you must execute:

     (asdf:operate 'asdf:load-op :ele-sqlite3)

depending on whether or not you wish to use the clsql backend or the BerkeleyDB backend, or both.

You will have to have the CL-SQL package installed. Following the documentation for CL-SQL under the section “How CLSQL finds and loads foreign libraries” you may need to do something like:

     (clsql:push-library-path "/usr/lib/")

before doing

     (asdf:oos 'asdf:load-op :clsql-postgresql-socket)

in order for clsql to find the PostGres library libpq.so, for example.

Without modifcation, Elephant uses this as it's lib path:

     /usr/local/share/common-lisp/elephant-0.3/

So you could put a symbolic link to libpq.so there, where libmemutil.so and libsleepycat.so will also reside.

Versions of CL-SQL older than 3.2.3 might require something different.