Elephant now keeps a small hashtables that maps “database specifications” into actual database connections.
If a database spec is a string, it is assumed to be a BerkeleyDB path. If it is a list, it is a assumed to be a CL-SQL connection specification. For example:
ELE-TESTS> *testdb-path* "/home/read/projects/elephant/elephant/tests/testdb/" ELE-TESTS> *testpg-path* (:postgresql "localhost.localdomain" "test" "postgres" "") ELE-TESTS>
The tests now have a function
do-all-tests-spec that take a spec and
based on its type attempt to open the correct kind of store controller and
perform the tests.
get-controller takes this specifiation.
The basic strategy is that the “database specification” object is stored in every persistent object and collection so that the repository can be found.
In this way, objects that reside in different repositories can coexist within the LISP object space, allowing data migration.