Next: Multi-repository Operation, Previous: Extention Status, Up: SQL back-end
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.