db
ARES System Manual: db Utility
If no recognized command is specified, the behavior depends on whether or not a space is present in the command. If a space is present,
The db utility provides tools for managing the system's LSD store (linkset datastore), which a shared memory heap used for message pipes, system and application settings, reading files, and more.
Unlike Companion, ARES has no database daemon. The LSD API allows programs to directly access and manipulate LSD data with synchronous calls, which is much more efficient.
When an LSD entry is used to store configuration settings, it is referred to as a 'section'. Sections are stored in the JSON file format and contain multiple 'keys', which represent individual settings.
Keys may be structured hierarchically depending on the data involved. For example,
Note that Linden Lab uses the word 'key' to refer to all string identifiers, such as JSON entries, LSD entries, items in the experience datastore, the UUIDs of SL objects, etc.
LSD entries that begin with
LSD entries that begin with
LSD entries that begin with
Loading database entries
ARES comes with some sample database files which can be loaded in case of a serious mistake, or to restore the system to factory defaults:
-
-
-
-
-
-
-
-
-
These can be loaded with the command
These directives are case-insensitive. Aside from
Similar directives are also used during database upgrades when new ARES versions are installed.
For more information on the JSON file format, see https://en.wikipedia.org/wiki/JSON
The database daemon in Companion was called
db [status]: lists extant sections and the current status of the LSD system.
db u|usage: lists all sections and pipe buffers, and their sizes.
db show <section>[.<key>]: prints contents of the specified section or key.
db [set] <section>[.<key>] <value>: modifies the specified section or key to contain a new value. The set keyword is mandatory if writing to a whole section.
db append <section>.<key> <value>: as set, but appending to existing contents.
db drop <section>: delete an entire section.
db delete|remove <section>.<key>: delete only the specified key.
db toggle <section>.<key>: alternates a key's value between 0 and 1.
db load <file>: load a text file from the file system (see fs) and add its entries to the database, overwriting any conflicts.
db clone <section>[.<key>] <section>[.<key>]: copy data from one section or key to another, overwriting existing contents.
If no recognized command is specified, the behavior depends on whether or not a space is present in the command. If a space is present,
set is assumed. Otherwise, show is assumed.
The db utility provides tools for managing the system's LSD store (linkset datastore), which a shared memory heap used for message pipes, system and application settings, reading files, and more.
Unlike Companion, ARES has no database daemon. The LSD API allows programs to directly access and manipulate LSD data with synchronous calls, which is much more efficient.
When an LSD entry is used to store configuration settings, it is referred to as a 'section'. Sections are stored in the JSON file format and contain multiple 'keys', which represent individual settings.
Keys may be structured hierarchically depending on the data involved. For example,
vox.output.enabled is a subkey of vox.output, which is a key that resides in the section vox.
Note that Linden Lab uses the word 'key' to refer to all string identifiers, such as JSON entries, LSD entries, items in the experience datastore, the UUIDs of SL objects, etc.
LSD entries that begin with
fs: are filesystem listings. See fs.
LSD entries that begin with
m: are menus. They use the same format as other db sections. See menu.
LSD entries that begin with
p: are pipe buffers. These are only visible in the db command when issuing db usage, and are usually deleted after reading. If you see a pipe buffer lingering, delete it with input purge.
Loading database entries
ARES comes with some sample database files which can be loaded in case of a serious mistake, or to restore the system to factory defaults:
-
badge.db specifies the default badges shown for various system models on the HUD interface
-
default.db covers the sections baseband, id, input, nav, status (partially), and trigger
-
font.db defines the default variatype fonts
-
fs.db covers the default filesystem settings
-
interface.db covers the interface section
-
menu.db covers the standard system menus
-
power.db covers the sections power and status (partially)
-
security.db covers the security system
-
vox.db covers the vox and filter sections
These can be loaded with the command
db load <name>, e.g. db load default.db. As with other system files, they are overwritten during an update, so make your own .db file if you wish to store your settings in this format.
db can read a few special directives when loading .db files:
SET <section>.<key> <value> sets the specified value, creating the section and key if necessary. (This is the default behavior - you may omit SET for brevity)
APPEND <section>.<key> <value> will assume the entry is a JSON list ([]) and append a new <value> to the end.
DELETE <section>.<key> will delete the entry.
CREATE <section>.<key> will create the entry only if it does not exist.
DROP <section> will delete an entire section.
MERGE <section>.<key> <json> will iterate over the keys of <json> and add them to the existing data in <section>.<key>. This is a shallow copy only; nested values will not be merged properly.
These directives are case-insensitive. Aside from
DROP they also have abbreviations:
SET is =
APPEND is ++
DELETE is -
CREATE is +
MERGE is +=
Similar directives are also used during database upgrades when new ARES versions are installed.
For more information on the JSON file format, see https://en.wikipedia.org/wiki/JSON
The database daemon in Companion was called
balance.