Basset::DB - talks to your database and gives you a few helper database methods.
Jim Thomason, firstname.lastname@example.org
#buried in the bowels of a module somewhere my $driver = Basset::DB->new(); my $stmt = $driver->prepare('select * from some_table');
You have a database. You're using Basset::Object::Persistent. You need to store objects. You need to talk to your database. You're using Basset::DB::Table for all of your table related stuff. But, some things are just simply database related (like connecting, transactions, etc.) for that, you need something higher. Basset::DB does just that.
Boolean attribute, set internally if the current transaction has been failed.
recreates the database handle with the original parameters. This will blindly blow away the DBI handle, so be careful with this method.
Takes a hash of values (dsh, user, pass) which are used to create a new database handel. By default, uses DBI's connect_cached method. Can be overridden in subclasses.
friggin' DBI cannot be subclassed. So AUTOLOAD sits in between. Any method called on a Basset::DB object that it doesn't understand creates a new method that passes through to the internal handle and calls the method on that. So, obviously, only use DBI methods.
This is your transaction stack for your driver. You will rarely (if ever) need to see this directly.
$driver->begin(); print $driver->stack(); #1 $driver->begin(); print $driver->stack(); #2 $driver->begin(); print $driver->stack(); #3
Adds 1 to your transaction stack
Subtracts 1 from your transaction stack.
automagically finishes your transaction and sets your stack back to 0, regardless of how many items are on your stack. Use this method with extreme care.
fails your transaction and rolls it back from the database. If you just want to fail your transaction but otherwise not roll it back, then simply set failed = 1.
unfails a transaction. If a fatal error occurs and you want to continue, you must unfail
fails your transaction and rolls it back from the database if you have pending items on your stack.
Copying Basset::DB objects is frowned upon. Nonetheless, if you must do it, you're still going to get the same database handle back. That is to say, the exact same object.
Note - as a result of how this has to work (and some DBI bitching), copying Basset::DB objects is not thread safe.
This is a wrapper method to DBI's sql_types constants. Pass in a string value consisting of the sql type string, and it spits back the relevant DBI constant.
my $some_constant = Basset::DB->sql_type('SQL_INTEGER');
Very useful if you're binding values or such.
returns an array of all tables in your database. You may optionally pass in a database handle to get all of the tables for that handle instead of the default
just a wrapper around DBI's ping
MySQL only, most likely. Calls the "optimize table" command on all tables in your database, or only upon those tables that you've passed in, if you prefer.
2 POD Errors
The following errors were encountered while parsing the POD:
- Around line 273:
'=item' outside of any '=over'
=over without closing =back
- Around line 312:
=over without closing =back