QDB databases are managed with a set of configuration objects, each of which configures one database. The configuration objects are text files that provide the paths to the database schema and storage files and specify policy settings such as backups.
By storing the separate databases in separate files, QDB allows you to dynamically load and unload individual databases so you can keep in memory only the data needed for the active client application.
For example, suppose you had two mediastores named mp3 and cdrom. You would then create configuration objects whose respective file names matched those of each of the two mediastores. For an overview of all database-related files, see "Summary of database files"
A database configuration object is a text file that gets parsed by QDB to set up the database. Blank lines are ignored, as is any leading or trailing white space. Lines specifying parameters are in the form key::value. Unknown parameter types are ignored and so they can be made into comments. You must still use the :: delimiter on the comment line for the encoding to be valid. For example, you can enter MyComment:: on a line and QDB will consider it to be an unsupported parameter and so will ignore that line when parsing the file.
The database is configured with the following parameters:
An initial schema is optional; without an initial schema, a new database will just be empty.
Note that this option is processed only if the Schema File option is set.
Use this feature for changing database settings that can't be premanently modified. An example would be the PRAGMA commands, which modify non-table data such as journaling mode or case-sensitive-like status. Don't use client schema files to do regular database work because doing so will slow down new connections.
You can also use this mechanism to implement cross-database triggers.
Attached databases are a convenience to provide access to tables that are physically stored in a different database file. This is useful for breaking up a database into separate pieces for performance reasons (each piece gets its own lock, which makes multi-user access more responsive). It's also useful for moving parts of a database to different storage medias (such as a RAM filesystem).
QDB allows you to include attached databases in other maintenance operations, such as backup or vacuum.
These directories must exist at loading time (though they don't need to contain valid backups); otherwise the loading attempt fails and QDB sets the database status to Error. If any existing backup files are located in these directories, they are sorted by date and overwritten oldest-to-newest when performing backup operations, and used in newest-to-oldest order when restoring a missing or corrupt database.
The lzo compression algorithm is the fastest, but the bzip algorithm offers the highest compression. Direct I/O doesn't perform any compression; instead, QDB uses an external utility to copy the database using direct memory access (DMA). Direct I/O is a fast way to back up data if the persistent storage supports DMA.
The compressed files are created with appropriate extensions added to the original database filename. By default, backup files aren't compressed.
Unlike the paths to other key files, the library file path can be relative or absolute. Relative paths are searched for in the library search directories (refer to the QNX Neutrino C Library Reference on dlopen() for more detail). You can also specify symbols from as many shared libraries as you want. For example, you could write:
Collation::UTF-8_Sort@libsort.so,UTF-16_Sort@libsort.so Function::sampleData@libstats.so,implToMtrc@libunits.so
For more information, see the Writing User-Defined Functions chapter.
QDB checks for the existence of the libraries and the specified symbols at loading time, and if any are not found, the loading attempt fails and QDB sets the database status to Error.
Here's a sample configuration for a database named mp3_tunes_0:
Filename::/fs/tmpfs/mp3_tunes_0 AutoAttach::mp3_tunes_1,mp3_tunes_2 VacuumAttached::mp3_tunes_1
In this example, a qdb_vacuum() operation on mp3_tunes_0 will also vacuum mp3_tunes_1 but not mp3_tunes_2.
For more details on the scope of maintenance operations for attached databases, refer to qdb_vacuum(), qdb_backup(), and qdb_getdbsize().
For example, you could specify BackupVia::/dev/shmem. When backing up, QDB locks the database, copies it to /dev/shmem, and then releases the lock. Then, in a second step, QDB performs the copy and compress operation into the location specified by BackupDir::, without needing to lock the database.