Encoded database
Since ODABA databases are based on "pointers", it becomes quite difficult to locate a specific piece of information without having the dictionary for the database. Hence, the dictionary is a sort of key for decoding data stored in the database. Nevertheless, ODABA supports further encoding technologies by using a binary access key. In order to encode data in the database, a binary key has to be provided always when accessing the database, i.e. beginning with the creation of the database.
The are different ways for providing access keys. In any case, binary keys have to be provided as ASCII text files coded in base64 (b64) or hexadecimal (hex) characters or plain text (txt). Text format is the most simple one to provide, but is less secure than base64 or hexadecimal because of the limited number of values.
The first line for the key declares the key encoding type prefixed and suffixed by '==='. After the format specification, any number of characters may follow until line break ('\n' or '\r\n'). The following key may contain any number of line breaks, which will be removed when creating the binary key.
Using encoded database access always requires the key for accessing data. Slight changes in the key will make access to the database impossible. Binary access keys may be provided in different ways.
===b64=== // base 64 encoded
===hex=== // hexadecimal
===txt=== // plain text
===fil=== // key passed in a file
The database definition in the dictionary provides an area fordefining an access key (ODC_Database.db_key). This is simple but uses the same key for all databases opened with this dictionary.
In order to avoid changes by accident, the key value should be write-protected after being set (see example below). ClassEditor provides an action for protecting the key after being entered.
... function( set<ODC_Database> &db_definition, odaba::String key ) {
if ( !db_definition.tryGet(0) )
db_definition.insert("mydb");
db_definition.db_key = key;
db_definition.db_key.save;
db_definition.db_key.writeProtected(true);
db_definition.top;
}
In order to become more flexible, especially, when defining the access key in the dictionary, the keys may refer to a file ('===fil==='). In this case, the next line of the key string is interpreted as file name (path), which may refer to the key string. The file path may contain option variables, which allow generic path definitions. This way, one may define the key in a dictionary/resource database, but refer to different keys for different users/application databases.
When using a data source definition in an ini-file, a key string file may be passed via the KEY_FILE option variable in the data source definition. The KEY_FILE option variable refers to a file that provides a string key as explained above for the database. Resource databases/dictionaries cannot be encoded. The key file will be read and the content passed to the database handle open function.
Passing a key file via KEY_FILE option and a key string defined in the dictionary, the key from the key file will be used.
A key string parameter may be passed to several open() functions for database handles. The key string parameter passed to the function must fulfill the key string conditions explained above.
Passing a key string and a key string is also defined in the dictionary, the key passed to the function will be used.