5.6 Setting up PostGres

To set up a PostGres based back end, you should:

1. Install postgres and make sure postmaster is running.
2. Create a database called “test” and set its permissions to be reached by whatever connection specification you intend to use. The tests use:

             (defvar *testpg-path*
             '(:postgreql "localhost.localdomain" "test" "postgres" ""))
        

   meaning that connections must be allowed to the database test, user “postgres”, no password, connected from the same machine “localhost.localdomain”. (This would be changed to something more secure in a real application.) Typically you edit the file : pg_hba.conf to enable various kinds of connections in postgres.

3. Be sure to enable socket connection to postgres when you invoke the postmaster.
4. Test that you can connect to the database with these credentials by running:

   psql -h 127.0.0.1 -U postgres test

   Before you attempt to connect with Elephant.

meaning that connections must be allowed to the database test, user “postgres”, no password, connected from the same machine “localhost.localdomain”. (This would be changed to something more secure in a real application.)

Furthermore, you must grant practically all creation/read/write privileges to the user postgres on this schema, so that it can construct the tables it needs.

Upon first opening a CL-SQL based store controller, the tables, indexes, sequences, and so on needed by the Elephant system will be created in the schema named “test” automatically.

To run the tests, execute:

     (asdf:operate 'asdf:load-op :elephant)
     (asdf:operate 'asdf:load-op :ele-clsql)
     (asdf:oos 'asdf:load-op :clsql-postgresql-socket)
     (in-package "ELEPHANT-TESTS")
     (do-all-tests-spec *testpg-path*)

This should produce a small number of errors (about 7) for those test having to do with migration and the BerkeleyDB system specifically.

If you execute:

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

Then connection to the BerkeleyDB system will be enabled, and you should be able to execute both

     (do-all-tests-spec *testpg-path*)
     (do-all-tests-spec *testdb-path*)

with no errors in either case.

At present the system has only been tested under PostGres. Some code parametrization would be required to work with other databases.

Setting up SQLite3 is even easier. Install SQLite3 (I had to use the source rather than the binary install, in order to get the dynamic libraries constructed.)

An example use of SQLLite3 would be:

     (asdf:operate 'asdf:load-op :elephant)
     (asdf:operate 'asdf:load-op :ele-clsql)
     (asdf:operate 'asdf:load-op :ele-sqlite3)
     (in-package "ELEPHANT-TESTS")
     (setq *test-path-primary* '(:sqlite3 "testdb"))
     (do-all-tests-spec *test-path-primary*)

The file RUNTESTS.lisp, although possibly not exactly what you want, contains useful example code.

You can of course migrate between the three currently supported repository strategies in any combination: BDB, Postgresql, and SQLite3.

In all probability, other relational datbases would be very easy to support but have not yet been tested. The basic pattern of the “path” specifiers is (cons clsqal-database-type-symbol (normal-clsql-connection-specifier)).