Note: If you are using Windows, we recommend that you install cygwin so you can use the Bash shell scripts we developed to simplify testing. Apache ant tasks should be utilized in the window shell.

Overview

When developing a collection, you need to determine what information in your collection you want to be searchable. This will determine what buckets are supported by your collection. This can be a difficult question. When asked, most people will say they want to have everything searchable. In practice, most search fields go unused, and often unpopulated. ADL has choosen to follow standard library practices, and recommends that collection developers implement a set of standard fields.

The present ADL system is geared towards database-backed collections. Developing database-backed collections presently requires the development of several configuration files:

• one main configuration file (bucket99.conf)
• three views templates and associated queries. View templates are called views because they generate a report that can be reformatted XML of a single metadata record, hence, a different view.
• one query to SQL translation file (query-translator.py).

This process can be daunting and frustrating. It requires that you know your database schema, and know SQL.

Developing configuration files

The following is the general process for developing these configuration files:

1. Develop the adl:bucket view and test it offline.
2. Develop the adl:access view and test it offline.
3. Develop the adl:browse view and test it offline.
4. Validate all views by validating views for all records.
5. Develop the query-translator test and it offline
6. Test in a live environment.

We have developed testing tools to assist in the development of collection configuration file for database-backed collection. These tools hide the command line calls to java classes. The tools are bash shell commands that call ant build files to set up the java classpath environment, and call the java classes.

Some important things to note

• For queries to work, the standard ADL reports must work (and be valid, if validation is turned on).
• Develop reports one at a time. Test even minor changes to a report. At present, an error in one report that uses bucket99.genericMetadataSubdriver can cause another report to fail. The genericMetadataSubdriver reports are a lightweight, high-performance templating engine.
• The query tests work offline—there is no guarantee they will work against a database. The tests only generate sample SQL.
• Be cautious when copying an already completed a configuration file. Be sure to change all parameters to match your configuration. Errors may not always be in the configuration region you are working on. For example, if the bucket99.conf:query.test_sql does not work, you will get a cannot connect to database error, even though your database_url is incorrect.