Configuration Files

Configuration File Definitions
Database Objects
Other Types of Objects
Cascading Configuration Files

The Firebird Vulcan configuration file system is a superset of the Firebird 1.5 configuration file. The full syntax and semantics are documented in section on Configuration Files.

Firebird Vulcan balances need for database and application specific configuration values and the need for system-wide management of configuration with cascading configuration files. The Firebird Vulcan configuration files control the mapping of databases to providers and security managers by defining those objects and their relationships.

Configuration File Definitions

Firebird Vulcan configuration files define parameters and objects. Configuration parameters are fixed attributes like the lock table hash width, sort memory size, etc. Configuration objects include databases, providers, servers, security managers, and other object types as yet unknown.

Configuration parameters that are declared globally within a configuration file become defaults.
Configuration parameters that are declared within the definition of an object are local to the object.
A global default parameter overrides an intrinsic, built-in default parameter of the same name.
A parameter defined within a provider object overrides the global default value for that parameter.
A parameter defined within a database object overrides the same parameter defined in the provider.
Parameters are scoped to support a balance between general policy and special case exceptions.

Database Objects

Database objects are described by a file name that may include wild cards. The database object description has one of two formats. The normal format includes a provider.

A general database object that includes a TCP/IP address. This object describes all databases which have a name that contains a ":" character. The filename is left unchanged and the designated provider is remote.

Thus, a request to open a database with a file name of "caine:/usr/harrison/databases/foo.fdb" would be passed to the TCP/IP remote access provider.
```
  <database *:*>
      filename    $0
      provider    remote
  </database>
        
```
a specific database object. This object describes all databases with the name "msg.fdb" and redefines the name to point to the message database in the Firebird Vulcan install directory.
```
  <database msg.fdb>
  filename    $(root)/databases/msg.fdb
  provider    engine11
  </database>
        
```
a generic database object. This object describes all other databases and assigns them to the local provider.
```
  <database *>
      filename    $0
      provider    engine11
  </database>
        
```
A second style of database object simply changes the name of the database. This is a useful feature, but its behavior is unlike anything else in the configuration files.

A database object definition can replace the name of the database without giving it any other characteristics. For example, some of the Firebird Vulcan and Firebird sources are modules that must be preprocessed by gpre. Those files contain the name of a database to use in the preprocessing. Many of them reference yachts.lnk . The build configuration file replaces the name “yachts.lnk” with a full path to a database called metadata.fdb.

When a database object definition replaces the name given on input, the configuration file manager reapplies all configuration files in order, using the new name rather than the name originally supplied.
```
  <database yachts.lnk>
       filename    caine:c:\harrison\Firebird Vulcan\databases\metadata.fdb
  </database>
        
```

Other Types of Objects

1: Provider Objects

This object is the local engine. Its attributes are the name and location of the lock file and the name and location of the shared libraries that can serve as that provider. In this case, the library can either be a 32-bit binary or a 64-bit binary.

The Y-valve will attempt to open a database with the first library lists, then the second, and so on.

  <provider engine11>
    LockFileName    $(root)/Firebird Vulcan.lck
    library         $(root)/bin/engine11 $(root)/bin64/engine11
  </provider>

The Y-valve is a degenerate provider, which accepts one parameter, TraceFlags , indicating that certain operations should be written to its output stream.

  <provider dispatch>
    TraceFlags	6
  </provider>

2: Security Objects

a) A security manager. At the moment there is only one security manager.

  <SecurityManager SecurityDb>
    SecurityDatabase  $(root)/security.fdb
    AuthAccount       user
    SecurityPlugin    SecurityDb
  </SecurityManager>

b) A security plugin. At the moment there is only one security plugin.

  <SecurityPlugin SecurityDb>
    library    $(root)/bin/securitydb $(root)/bin64/securitydb
  </SecurityPlugin>

Cascading Configuration Files

The second major difference between Firebird Vulcan and Firebird configuration files is that Firebird Vulcan configuration files cascade. The Y-valve opens an initial configuration file that can provide all parameter and object definitions, like firebird.conf, or it can provide some definitions and include one or more additional configuration files. Those files can include other configuration files.

Typically, the initial configuration file is the most specific and the included files are increasingly generic, ending with firebird.conf.

Objects can be defined at multiple levels. An earlier object definition overrides a later object definition. A system manager can choose to delegate control over various group databases to the groups themselves while retaining control over server configurations. An individual (or application program) can specify a personal or application configuration file that cascades to the group configuration file that cascades to the system wide client configuration files.