Provided by: ledgersmb_1.3.46-1_all 
NAME
LedgerSMB::Database - Provides the APIs for database creation and management.
SYNOPSIS
This module provides the APIs for database creation and management
COPYRIGHT
This module is copyright (C) 2007, the LedgerSMB Core Team and subject to the GNU General
Public License (GPL) version 2, or at your option, any later version. See the COPYRIGHT
and LICENSE files for more information.
METHODS
LedgerSMB::Database->new({dbname = $dbname, countrycode = $cc, chart_name = $name,
company_name = $company, username = $username, password = $password})
This function creates a new database management object with the specified
characteristics. The $dbname is the name of the database. the countrycode is the two-
letter ISO code. The company name is the friendly name for dropdown boxes on the
Login screen.
As some countries may have multiple available charts, you can also specify a chart
name as well.
Note that the arguments can be any hashref. If it is a LedgerSMB object, however, it
will attempt to copy all attributes beginning with _ into the current object (_user,
_locale, etc).
base_backup
This routine connects to the database using pg_dumpall and returns a plain text,
roles-only dump of the current database cluster. This is left uncompressed for
readability and ease of troubleshooting. Base backups are advised to be taken
frequently and in conjunction with single database backups. The single database
backups will backup all data but no roles. Restoring a new database onto a new server
post-crash with only the single-database backup thus means recreating all users.
The file is named roles_[date].sql by default where the date is in yyyy-mm-dd format.
It returns the full path of the resulting backup file on success, or undef on failure.
db_backup()
This routine connects to the database using pg_dump and creates a Pg-native database
backup of the selected db only. There is some redundancy with the base backup but the
overlap is minimal. You can restore your database and data with the db_bakup, but not
the users and roles. You can restore the users and roles with the base_backup but not
your database.
The resulting file is named backup_[dbname]_[date].bak with the date in yyyy-mm-dd
format.
It returns the full path of the resulting backup file on success, or undef on failure.
get_info()
This routine connects to the database using DBI and attempts to determine if a related
application is running in that database and if so what version. It returns a hashref
with the following keys set:
username
Set to the user of the current connection
appname
Set to the current application name, one of:
ledgersmb
sql-ledger
undef
version
The current version of the application. One of:
legacy
SQL-Ledger 2.6 and below, and LedgerSMB 1.1 and below
1.2 (LedgerSMB only)
1.3 (LedgerSMB only)
1.3dev (LedgerSMB only)
2.7 (SQL-Ledger only)
2.8 (SQL-Ledger only)
full_version
The full version number of the database version
status
Current status of the db. One of:
exists
The database was confirmed to exist
does not exist
The database was confirmed to not exist
undef
The database could not be confirmed to exist, or not
It is worth noting that this is designed to be informative and helpful in determining
whether automatic upgrades can in fact occur or other administrative tasks can be run.
Sample output might be:
{ appname => undef,
version => undef, full_version => undef,
status => 'does not exist'}
or
{ appname => 'sql-ledger',
version => '2.8', full_version => '2.8.33',
status => 'exists'}
or
{ appname => 'ledgersmb',
version => '1.2' fullversion => '1.2.0',
status => 'exists' }
It goes without saying that status will always equal 'exists' if appname is set.
However the converse is not true. If the status is 'exists' and appname is not set,
this merely means that the database exists but is not used by a recognized
application. So administrative functions are advised to check both the appname and
status values.
Finally, it is important to note that LedgerSMB 1.1 and prior, and SQL-Ledger 2.6.x
and prior are lumped under appname => 'ledgersmb' and version => 'legacy', though the
fullversion may give you an idea of what the actual version is run.
$db->server_version();
Connects to the server and returns the version number in x.y.z format.
$db->list()
Lists available databases except for those named "postgres" or starting with
"template"
Returns a list of strings of db names.
$db->create();
Creates a database and loads the contrib files. This is done from template0, meaning
nothing added to template1 will be found in this database. This was necessary as a
workaround for issues on some Debian systems.
Returns true if successful, false of not. Creates a log called dblog in the temporary
directory with all the output from the psql files.
In DEBUG mode, will show all lines to STDERR. In ERROR logging mode, will display
only those lines containing the word ERROR.
$db->copy('new_name')
Copies the existing database to a new name.
$db->load_modules($loadorder)
Loads or reloads sql modules from $loadorder
$db->exec_script({script => 'path/to/file', logfile => 'path/to/log'})
Executes the script. Returns 0 if successful, 1 if there are errors suggesting that
types are already created, and 2 if there are other errors.
$db->create_and_load();
Creates a database and then loads it.
$db->process_roles($rolefile);
Loads database Roles templates.
$db->lsmb_info()
This routine retrieves general stats about the database and returns the output as a
hashref with the following key/value pairs:
ar_rows
ap_rows
gl_rows
acc_trans_rows
eca_rows
oe_rows
transactions_rows
users_rows
$db->db_tests()
This routine runs general db tests.
TODO