Group :: Development/Perl
RPM: perl-Ima-DBI
Navigation
Main Changelog Spec Patches Sources Download Gear Bugs and FR Repocop
pax_global_header 0000666 0000000 0000000 00000000064 10633061073 0014511 g ustar 00root root 0000000 0000000 52 comment=d553133e921545b7ac0f89767e68a8484daa1883
Ima-DBI-0.35/ 0000755 0000000 0000000 00000000000 10633061073 0012540 5 ustar 00root root 0000000 0000000 Ima-DBI-0.35/Changes 0000644 0000000 0000000 00000012212 10633061073 0014031 0 ustar 00root root 0000000 0000000 Revision history for Perl extension Ima::DBI.
0.35 Sun Jun 10 16:36:07 EST 2007
- Add checking of PID in database handles to prevent trouble
in forked environments (Perrin Harkins and Sam Tregar)
0.34 Mon Sep 5 09:10:37 UTC 2005
- Remove Class::WhiteHole from PREREQs (Alexey Tourbin)
0.33 Mon Mar 15 19:33:11 GMT 2004
- We're no longer a subclass of DBI directly. Instead we use
DBIx::ContextualFetch
0.32 Sat Feb 28 10:13:42 GMT 2004
- Fix minor bug in set_sql relating to method names containing
spaces [Davide Dente]
0.31 Tue Oct 14 21:55:08 BST 2003
- call finish() on $sth in select_col
0.30 Sat Sep 27 11:15:28 BST 2003
- added (undocumented) select_row, select_col, select_val helper
methods to $sth. These may change in a later release.
0.29 Sun Jun 22 15:50:12 BST 2003
- Allow subclasses to provide their own transform_sql method
0.28 Fri Jan 3 16:23:04 GMT 2003
- stop sql_closure holding a lexical $sth
0.27 Sat Feb 16 11:55:23 GMT 2002
- fix precedence bug with commit / rollback
[thanks to Tim Ayers]
- Subclassing DBI is now greatly improved thanks to changes
in DBI itself.
- DBI now handles all taint issues for us directly
0.26 Sat Oct 6 12:38:21 BST 2001
[now maintainted by Tony Bowden]
- Allow setting with overloaded values
- Lots of doc patches by Wesley Darlington
- Switch tests to Test::More
- removed Ima::DBI::utility
0.25 Sun Apr 8 23:55:15 BST 2001
- Fixed a minor bug with %% in SQL
- Cleaned up the docs a bit
* Added db_names() and db_handles()
* Added sql_names()
* Implemented commit() and rollback()
- Fixed minor bug in assertion on set_db()
0.24 Sun Sep 10 00:50:15 EDT 2000
- *bug fix* commit() and rollback() were accidentally broken on
database handles
0.23 Sun Jul 9 04:57:51 EDT 2000
- Fixed accidental AutoLoader inheritance.
0.22 Sun Jul 2 19:51:53 EDT 2000 *UNRELEASED*
- Upon encountering an already active handle, sql_* was mistakenly
croak()ing instead of carp()ing.
0.21 Thu Apr 20 14:36:17 EDT 2000
- Added a new caching argument to set_sql()
- Removed the assert() using a 5.005 feature to keep things 5.004
clean.
0.20 Wed Apr 19 20:46:57 EDT 2000
- set_sql() required its database method to have been declared previous
to it being called. This turns out to be unnecessary and gets in
the way of writing a virtual base class which defines statements
but not the database connection.
0.19 Wed Apr 12 23:18:48 EST 2000
- Now using DBI->init_rootclass to pull off DBI subclassing. This
means subclasses of Ima::DBI should always get Ima::DBI::st and
Ima::DBI::db objects no matter what they pull.
0.18 Thu Mar 16 16:04:11 EST 2000
* Ooops, bug in fetch_hash() in list context.
0.17 Tue Feb 29 00:13:32 EST 2000
* set_sql() and sql_*() will now deal with dynamic SQL statements much
better.
- Fixed up the docs a bit.
- execute() no longer checks for taintedness on bind parameters.
0.16 1999/12/29 06:37:03
* Added a real DBIwarn()
- Never released to CPAN.
0.15 1999/12/14 23:33:37
- Minor efficiency improvement of set_db().
- Minor adjustment to set_sql() so that the generated method calls
db_*() internaly instead of holding the $dbh inside the closure.
This allows subclasses to override the db_*() for that particular
sql method (needed for Class::DBI)
0.14 1999/12/08 00:56:58
* fetchall_hash() was incorrectly coded as fetchall_hashref().
0.13 1999/09/26 21:53:27
* DBI::st::bind_columns() was being called improperly
0.12 Mon Sep 20 18:04:58 EDT 1999
- Fixed that damned pod2man warning about "Unmatched =back" (thanks Addi)
- Lowered the restrictions on execute() to allow execute(undef, \@cols)
0.11 Tue Jul 20 22:08:35 EDT 1999
- Added prepare() override to return Ima::DBI style statement handles.
0.10 Mon Jul 19 20:04:04 EDT 1999
- Updated TODO list
- Added COPYRIGHT and licensing
- Performance improvement by drastically reducting # of calls to
DBI::prepare_cached
0.09 Tue Jul 13 23:59:56 EDT 1999
- Major performance improvement by drasticly reducing # of calls to
DBI::connect_cached.
0.08 Wed Jun 30 16:16:16 EDT 1999
* Spaces in names of statements and database (sql_ and db_) are now
translate to underscores.
0.07 Tue May 19 20:58:02 EDT 1999
- Cleaning up use of DBI's tainting features.
0.06 Sat May 8 03:50:34 EDT 1999
- Implements data tainting via DBI->{Taint} (Thanks, Tim!)
0.05 Tue May 4 22:08:56 EDT 1999
* code for tainting fetched data added
- taint check repaired, but still incomplete.
- manual tainting repaired, but still incomplete.
0.04 Mon May 3 22:14:02 EDT 1999
- tests added
- parts still imcomplete
- usable, I guess.
0.04pre Fri Apr 30 20:10:38 EDT 1999
* PRE RELEASE, UNTESTED
* Complete re-write from the ground up.
* Major API changes. See docs.
* taint added
* Requires DBI 1.06
* Parts still incomplete
0.03 I forget
* BROKEN BROKEN BROKEN!
0.01 Fri Apr 3 19:19:48 1998
- original version; created by h2xs 1.18
Ima-DBI-0.35/INSTALL 0000644 0000000 0000000 00000001055 10633061073 0013572 0 ustar 00root root 0000000 0000000 WHAT IS THIS?
This is Ima::DBI, a perl module. Please see the README that comes with
this distribution.
HOW DO I INSTALL IT?
To install this module, cd to the directory that contains this README
file and type the following:
perl Makefile.PL
make
make test
make install
To install this module into a specific directory, do:
perl Makefile.PL PREFIX=/name/of/the/directory
...the rest is the same...
Please also read the perlmodinstall man page, if available.
Requires:
Carp::Assert 0.05 and up
DBI 1.09 and up
Ima-DBI-0.35/MANIFEST 0000644 0000000 0000000 00000000172 10633061073 0013671 0 ustar 00root root 0000000 0000000 Changes
INSTALL
lib/Ima/DBI.pm
Makefile.PL
MANIFEST This list of files
META.yml
README
t/DBI.t
t/pod-coverage.t
t/pod.t
Ima-DBI-0.35/META.yml 0000644 0000000 0000000 00000000706 10633061073 0014014 0 ustar 00root root 0000000 0000000 # http://module-build.sourceforge.net/META-spec.html
#XXXXXXX This is a prototype!!! It will change in the future!!! XXXXX#
name: Ima-DBI
version: 0.35
version_from: lib/Ima/DBI.pm
installdirs: site
requires:
Class::Data::Inheritable: 0.02
DBI: 1.2
DBIx::ContextualFetch: 1
Test::More: 0.18
distribution_type: module
generated_by: ExtUtils::MakeMaker version 6.30
Ima-DBI-0.35/Makefile.PL 0000644 0000000 0000000 00000001452 10633061073 0014514 0 ustar 00root root 0000000 0000000 use ExtUtils::MakeMaker;
my $LAST_API_CHANGE = 0.08;
eval { require Ima::DBI; };
unless ($@) { # Make sure we did find the module.
print <<"CHANGE_WARN" if $Ima::DBI::VERSION < $LAST_API_CHANGE;
NOTE: There have been API changes between this version and any older
than version $LAST_API_CHANGE! Please read the Changes file if you
are upgrading from a version of Ima::DBI older than $LAST_API_CHANGE.
CHANGE_WARN
}
WriteMakefile(
NAME => 'Ima::DBI',
VERSION_FROM => 'lib/Ima/DBI.pm',
PREREQ_PM => {
'DBI' => 1.20,
'Class::Data::Inheritable' => 0.02,
'DBIx::ContextualFetch' => 1.00,
'Test::More' => 0.18,
},
(
$] > 5.005
? ()
: (
ABSTRACT_FROM => 'lib/Ima/DBI.pm',
AUTHOR => 'Tony Bowden <kasei@tmtm.com>',
)
),
);
Ima-DBI-0.35/README 0000644 0000000 0000000 00000046377 10633061073 0013441 0 ustar 00root root 0000000 0000000 NAME
Ima::DBI - Database connection caching and organization
SYNOPSIS
package Foo;
use base 'Ima::DBI';
# Class-wide methods.
Foo->set_db($db_name, $data_source, $user, $password);
Foo->set_db($db_name, $data_source, $user, $password, \%attr);
my @database_names = Foo->db_names;
my @database_handles = Foo->db_handles;
Foo->set_sql($sql_name, $statement, $db_name);
Foo->set_sql($sql_name, $statement, $db_name, $cache);
my @statement_names = Foo->sql_names;
# Object methods.
$dbh = $obj->db_*; # Where * is the name of the db connection.
$sth = $obj->sql_*; # Where * is the name of the sql statement.
$sth = $obj->sql_*(@sql_pieces);
$obj->DBIwarn($what, $doing);
my $rc = $obj->commit;
my $rc = $obj->commit(@db_names);
my $rc = $obj->rollback;
my $rc = $obj->rollback(@db_names);
DESCRIPTION
Ima::DBI attempts to organize and facilitate caching and more efficient
use of database connections and statement handles by storing DBI and SQL
information with your class (instead of as seperate objects). This
allows you to pass around just one object without worrying about a trail
of DBI handles behind it.
One of the things I always found annoying about writing large programs
with DBI was making sure that I didn't have duplicate database handles
open. I was also annoyed by the somewhat wasteful nature of the
prepare/execute/finish route I'd tend to go through in my subroutines.
The new DBI->connect_cached and DBI->prepare_cached helped a lot, but I
still had to throw around global datasource, username and password
information.
So, after a while I grew a small library of DBI helper routines and
techniques. Ima::DBI is the culmination of all this, put into a nice(?),
clean(?) class to be inherited from.
Why should I use this thing?
Ima::DBI is a little odd, and it's kinda hard to explain. So lemme
explain why you'd want to use this thing...
* Consolidation of all SQL statements and database information
No matter what, embedding one language into another is messy. DBI
alleviates this somewhat, but I've found a tendency to have that
scatter the SQL around inside the Perl code. Ima::DBI allows you to
easily group the SQL statements in one place where they are easier
to maintain (especially if one developer is writing the SQL, another
writing the Perl). Alternatively, you can place your SQL statement
alongside the code which uses it. Whatever floats your boat.
Database connection information (data source, username, password,
atrributes, etc...) can also be consolidated together and tracked.
Both the SQL and the connection info are probably going to change a
lot, so having them well organized and easy to find in the code is a
Big Help.
* Holds off opening a database connection until necessary.
While Ima::DBI is informed of all your database connections and SQL
statements at compile-time, it will not connect to the database
until you actually prepare a statement on that connection.
This is obviously very good for programs that sometimes never touch
the database. It's also good for code that has lots of possible
connections and statements, but which typically only use a few.
Kinda like an autoloader.
* Easy integration of the DBI handles into your class
Ima::DBI causes each database handle to be associated with your
class, allowing you to pull handles from an instance of your object,
as well as making many oft-used DBI methods available directly from
your instance.
This gives you a cleaner OO design, since you can now just throw
around the object as usual and it will carry its associated DBI
baggage with it.
* Honors taint mode
It always struck me as a design deficiency that tainted SQL
statements could be passed to $sth->prepare(). For example:
# $user is from an untrusted source and is tainted.
$user = get_user_data_from_the_outside_world;
$sth = $dbh->prepare('DELETE FROM Users WHERE User = $user');
Looks innocent enough... but what if $user was the string "1 OR User
LIKE '%'". You just blew away all your users. Hope you have backups.
Ima::DBI turns on the DBI->connect Taint attribute so that all DBI
methods (except execute()) will no longer accept tainted data. See
"Taint" in DBI for details.
* Taints returned data
Databases should be like any other system call. It's the scary
Outside World, thus it should be tainted. Simple. Ima::DBI turns on
DBI's Taint attribute on each connection. This feature is
overridable by passing your own Taint attribute to set_db as normal
for DBI. See "Taint" in DBI for details.
* Encapsulation of some of the more repetitive bits of everyday DBI
usage
I get lazy a lot and I forget to do things I really should, like
using bind_cols(), or rigorous error checking. Ima::DBI does some of
this stuff automatically, other times it just makes it more
convenient.
* Encapsulation of DBI's cache system
DBI's automatic handle caching system is relatively new, and some
people aren't aware of its use. Ima::DBI uses it automatically, so
you don't have to worry about it. (It even makes it a bit more
efficient)
* Sharing of database and sql information amongst inherited classes
Any SQL statements and connections created by a class are available
to its children via normal method inheritance.
* Guarantees one connection per program.
One program, one database connection (per database user). One
program, one prepared statement handle (per statement, per database
user). That's what Ima::DBI enforces. Extremely handy in persistant
environments (servers, daemons, mod_perl, FastCGI, etc...)
* Encourages use of bind parameters and columns
Bind parameters are safer and more efficient than embedding the
column information straight into the SQL statement. Bind columns are
more efficient than normal fetching. Ima::DBI pretty much requires
the usage of the former, and eases the use of the latter.
Why shouldn't I use this thing.
* It's all about OO
Although it is possible to use Ima::DBI as a stand-alone module as
part of a function-oriented design, its generally not to be used
unless integrated into an object-oriented design.
* Overkill for small programs
* Overkill for programs with only one or two SQL statements
Its up to you whether the trouble of setting up a class and jumping
through the necessary Ima::DBI hoops is worth it for small programs.
To me, it takes just as much time to set up an Ima::DBI subclass as
it would to access DBI without it... but then again I wrote the
module. YMMV.
* Overkill for programs that only use their SQL statements once
Ima::DBI's caching might prove to be an unecessary performance hog
if you never use the same SQL statement twice. Not sure, I haven't
looked into it.
USAGE
The basic steps to "DBIing" a class are:
1 Inherit from Ima::DBI
2 Set up and name all your database connections via set_db()
3 Set up and name all your SQL statements via set_sql()
4 Use sql_* to retrieve your statement handles ($sth) as needed and
db_* to retreive database handles ($dbh).
Have a look at EXAMPLE below.
TAINTING
Ima::DBI, by default, uses DBI's Taint flag on all connections.
This means that Ima::DBI methods do not accept tainted data, and that
all data fetched from the database will be tainted. This may be
different from the DBI behavior you're used to. See "Taint" in DBI for
details.
Class Methods
set_db
Foo->set_db($db_name, $data_source, $user, $password);
Foo->set_db($db_name, $data_source, $user, $password, \%attr);
This method is used in place of DBI->connect to create your database
handles. It sets up a new DBI database handle associated to $db_name.
All other arguments are passed through to DBI->connect_cached.
A new method is created for each db you setup. This new method is called
"db_$db_name"... so, for example, Foo->set_db("foo", ...) will create a
method called "db_foo()". (Spaces in $db_name will be translated into
underscores: '_')
%attr is combined with a set of defaults (RaiseError => 1, AutoCommit =>
0, PrintError => 0, Taint => 1). This is a better default IMHO, however
it does give databases without transactions (such as MySQL when used
with the default MyISAM table type) a hard time. Be sure to turn
AutoCommit back on if your database does not support transactions.
The actual database handle creation (and thus the database connection)
is held off until a prepare is attempted with this handle.
set_sql
Foo->set_sql($sql_name, $statement, $db_name);
Foo->set_sql($sql_name, $statement, $db_name, $cache);
This method is used in place of DBI->prepare to create your statement
handles. It sets up a new statement handle associated to $sql_name using
the database connection associated with $db_name. $statement is passed
through to either DBI->prepare or DBI->prepare_cached (depending on
$cache) to create the statement handle.
If $cache is true or isn't given, then prepare_cached() will be used to
prepare the statement handle and it will be cached. If $cache is false
then a normal prepare() will be used and the statement handle will be
recompiled on every sql_*() call. If you have a statement which changes
a lot or is used very infrequently you might not want it cached.
A new method is created for each statement you set up. This new method
is "sql_$sql_name"... so, as with set_db(), Foo->set_sql("bar", ...,
"foo"); will create a method called "sql_bar()" which uses the database
connection from "db_foo()". Again, spaces in $sql_name will be
translated into underscores ('_').
The actual statement handle creation is held off until sql_* is first
called on this name.
transform_sql
To make up for the limitations of bind parameters, $statement can
contain sprintf() style formatting (ie. %s and such) to allow
dynamically generated SQL statements (so to get a real percent sign, use
'%%').
The translation of the SQL happens in transform_sql(), which can be
overridden to do more complex transformations. See Class::DBI for an
example.
db_names / db_handles
my @database_names = Foo->db_names;
my @database_handles = Foo->db_handles;
my @database_handles = Foo->db_handles(@db_names);
Returns a list of the database handles set up for this class using
set_db(). This includes all inherited handles.
db_names() simply returns the name of the handle, from which it is
possible to access it by converting it to a method name and calling that
db method...
my @db_names = Foo->db_names;
my $db_meth = 'db_'.$db_names[0];
my $dbh = $foo->$db_meth;
Icky, eh? Fortunately, db_handles() does this for you and returns a list
of database handles in the same order as db_names(). Use this sparingly
as it will connect you to the database if you weren't already connected.
If given @db_names, db_handles() will return only the handles for those
connections.
These both work as either class or object methods.
sql_names
my @statement_names = Foo->sql_names;
Similar to db_names() this returns the names of all SQL statements set
up for this class using set_sql(), inherited or otherwise.
There is no corresponding sql_handles() because we can't know what
arguments to pass in.
Object Methods
db_*
$dbh = $obj->db_*;
This is how you directly access a database handle you set up with
set_db.
The actual particular method name is derived from what you told set_db.
db_* will handle all the issues of making sure you're already connected
to the database.
sql_*
$sth = $obj->sql_*;
$sth = $obj->sql_*(@sql_pieces);
sql_*() is a catch-all name for the methods you set up with set_sql().
For instance, if you did:
Foo->set_sql('GetAllFoo', 'Select * From Foo', 'SomeDb');
you'd run that statement with sql_GetAllFoo().
sql_* will handle all the issues of making sure the database is already
connected, and the statement handle is prepared. It returns a prepared
statement handle for you to use. (You're expected to execute() it)
If sql_*() is given a list of @sql_pieces it will use them to fill in
your statement, assuming you have sprintf() formatting tags in your
statement. For example:
Foo->set_sql('GetTable', 'Select * From %s', 'Things');
# Assuming we have created an object... this will prepare the
# statement 'Select * From Bar'
$sth = $obj->sql_Search('Bar');
Be very careful with what you feed this function. It cannot do any
quoting or escaping for you, so it is totally up to you to take care of
that. Fortunately if you have tainting on you will be spared the worst.
It is recommended you only use this in cases where bind parameters will
not work.
DBIwarn
$obj->DBIwarn($what, $doing);
Produces a useful error for exceptions with DBI.
I'm not particularly happy with this interface
Most useful like this:
eval {
$self->sql_Something->execute($self->{ID}, @stuff);
};
if($@) {
$self->DBIwarn($self->{ID}, 'Something');
return;
}
Modified database handle methods
Ima::DBI makes some of the methods available to your object that are
normally only available via the database handle. In addition, it spices
up the API a bit.
commit
$rc = $obj->commit;
$rc = $obj->commit(@db_names);
Derived from $dbh->commit() and basically does the same thing.
If called with no arguments, it causes commit() to be called on all
database handles associated with $obj. Otherwise it commits all database
handles whose names are listed in @db_names.
Alternatively, you may like to do: $rc = $obj->db_Name->commit;
If all the commits succeeded it returns true, false otherwise.
rollback
$rc = $obj->rollback;
$rc = $obj->rollback(@db_names);
Derived from $dbh->rollback, this acts just like Ima::DBI->commit,
except that it calls rollback().
Alternatively, you may like to do: $rc = $obj->db_Name->rollback;
If all the rollbacks succeeded it returns true, false otherwise.
EXAMPLE
package Foo;
use base qw(Ima::DBI);
# Set up database connections (but don't connect yet)
Foo->set_db('Users', 'dbi:Oracle:Foo', 'admin', 'passwd');
Foo->set_db('Customers', 'dbi:Oracle:Foo', 'Staff', 'passwd');
# Set up SQL statements to be used through out the program.
Foo->set_sql('FindUser', <<"SQL", 'Users');
SELECT *
FROM Users
WHERE Name LIKE ?
SQL
Foo->set_sql('ChangeLanguage', <<"SQL", 'Customers');
UPDATE Customers
SET Language = ?
WHERE Country = ?
SQL
# rest of the class as usual.
package main;
$obj = Foo->new;
eval {
# Does connect & prepare
my $sth = $obj->sql_FindUser;
# bind_params, execute & bind_columns
$sth->execute(['Likmi%'], [\($name)]);
while( $sth->fetch ) {
print $name;
}
# Uses cached database and statement handles
$sth = $obj->sql_FindUser;
# bind_params & execute.
$sth->execute('%Hock');
@names = $sth->fetchall;
# connects, prepares
$rows_altered = $obj->sql_ChangeLanguage->execute(qw(es_MX mx));
};
unless ($@) {
# Everything went okay, commit the changes to the customers.
$obj->commit('Customers');
}
else {
$obj->rollback('Customers');
warn "DBI failure: $@";
}
USE WITH MOD_PERL, FASTCGI, ETC.
To help with use in forking environments, Ima::DBI database handles keep
track of the PID of the process they were openend under. If they notice
a change (because you forked a new process), a new handle will be opened
in the new process. This prevents a common problem seen in environments
like mod_perl where people would open a handle in the parent process and
then run into trouble when they try to use it from a child process.
Because Ima::DBI handles keeping database connections persistent and
prevents problems with handles openend before forking, it is not
necessary to use Apache::DBI when using Ima::DBI. However, there is one
feature of Apache::DBI which you will need in a mod_perl or FastCGI
environment, and that's the automatic rollback it does at the end of
each request. This rollback provides safety from transactions left
hanging when some perl code dies -- a serious problem which could grind
your database to a halt with stale locks.
To replace this feature on your own under mod_perl, you can add
something like this in a handler at any phase of the request:
$r->push_handlers(PerlCleanupHandler => sub {
MyImaDBI->rollback();
});
Here "MyImaDBI" is your subclass of Ima::DBI. You could also make this
into an actual module and set the PerlCleanupHandler from your
httpd.conf. A similar approach should work in any long-running
environment which has a hook for running some code at the end of each
request.
TODO, Caveat, BUGS, etc....
I seriously doubt that it's thread safe.
You can bet cupcackes to sno-cones that much havoc will be wrought
if Ima::DBI is used in a threaded Perl.
Should make use of private_* handle method to store information
The docs stink.
The docs were originally written when I didn't have a good handle on
the module and how it will be used in practical cases. I need to
rewrite the docs from the ground up.
Need to add debugging hooks.
The thing which immediately comes to mind is a Verbose flag to print
out SQL statements as they are made as well as mention when database
connections are made, etc...
MAINTAINERS
Tony Bowden <tony@tmtm.com> and Perrin Harkins <perrin@elem.com>
ORIGINAL AUTHOR
Michael G Schwern <schwern@pobox.com>
LICENSE
This module is free software. You may distribute under the same terms as
Perl itself. IT COMES WITHOUT WARRANTY OF ANY KIND.
THANKS MUCHLY
Tim Bunce, for enduring many DBI questions and adding Taint,
prepare_cached and connect_cached methods to DBI, simplifying this
greatly!
Arena Networks, for effectively paying for Mike to write most of this
module.
SEE ALSO
DBI.
You may also choose to check out Class::DBI which hides most of this
from view.
Ima-DBI-0.35/lib/ 0000755 0000000 0000000 00000000000 10633061073 0013306 5 ustar 00root root 0000000 0000000 Ima-DBI-0.35/lib/Ima/ 0000755 0000000 0000000 00000000000 10633061073 0014014 5 ustar 00root root 0000000 0000000 Ima-DBI-0.35/lib/Ima/DBI.pm 0000644 0000000 0000000 00000054111 10633061073 0014752 0 ustar 00root root 0000000 0000000 package Ima::DBI;
$VERSION = '0.35';
use strict;
use base 'Class::Data::Inheritable';
use DBI;
# Some class data to store a per-class list of handles.
Ima::DBI->mk_classdata('__Database_Names');
Ima::DBI->mk_classdata('__Statement_Names');
=head1 NAME
Ima::DBI - Database connection caching and organization
=head1 SYNOPSIS
package Foo;
use base 'Ima::DBI';
# Class-wide methods.
Foo->set_db($db_name, $data_source, $user, $password);
Foo->set_db($db_name, $data_source, $user, $password, \%attr);
my @database_names = Foo->db_names;
my @database_handles = Foo->db_handles;
Foo->set_sql($sql_name, $statement, $db_name);
Foo->set_sql($sql_name, $statement, $db_name, $cache);
my @statement_names = Foo->sql_names;
# Object methods.
$dbh = $obj->db_*; # Where * is the name of the db connection.
$sth = $obj->sql_*; # Where * is the name of the sql statement.
$sth = $obj->sql_*(@sql_pieces);
$obj->DBIwarn($what, $doing);
my $rc = $obj->commit;
my $rc = $obj->commit(@db_names);
my $rc = $obj->rollback;
my $rc = $obj->rollback(@db_names);
=head1 DESCRIPTION
Ima::DBI attempts to organize and facilitate caching and more efficient
use of database connections and statement handles by storing DBI and
SQL information with your class (instead of as seperate objects).
This allows you to pass around just one object without worrying about
a trail of DBI handles behind it.
One of the things I always found annoying about writing large programs
with DBI was making sure that I didn't have duplicate database handles
open. I was also annoyed by the somewhat wasteful nature of the
prepare/execute/finish route I'd tend to go through in my subroutines.
The new DBI->connect_cached and DBI->prepare_cached helped a lot, but
I still had to throw around global datasource, username and password
information.
So, after a while I grew a small library of DBI helper routines and
techniques. Ima::DBI is the culmination of all this, put into a nice(?),
clean(?) class to be inherited from.
=head2 Why should I use this thing?
Ima::DBI is a little odd, and it's kinda hard to explain. So lemme
explain why you'd want to use this thing...
=over 4
=item * Consolidation of all SQL statements and database information
No matter what, embedding one language into another is messy.
DBI alleviates this somewhat, but I've found a tendency to have that
scatter the SQL around inside the Perl code. Ima::DBI allows you to
easily group the SQL statements in one place where they are easier to
maintain (especially if one developer is writing the SQL, another writing
the Perl). Alternatively, you can place your SQL statement alongside
the code which uses it. Whatever floats your boat.
Database connection information (data source, username, password,
atrributes, etc...) can also be consolidated together and tracked.
Both the SQL and the connection info are probably going to change a lot,
so having them well organized and easy to find in the code is a Big Help.
=item * Holds off opening a database connection until necessary.
While Ima::DBI is informed of all your database connections and SQL
statements at compile-time, it will not connect to the database until
you actually prepare a statement on that connection.
This is obviously very good for programs that sometimes never touch
the database. It's also good for code that has lots of possible
connections and statements, but which typically only use a few.
Kinda like an autoloader.
=item * Easy integration of the DBI handles into your class
Ima::DBI causes each database handle to be associated with your class,
allowing you to pull handles from an instance of your object, as well
as making many oft-used DBI methods available directly from your
instance.
This gives you a cleaner OO design, since you can now just throw
around the object as usual and it will carry its associated DBI
baggage with it.
=item * Honors taint mode
It always struck me as a design deficiency that tainted SQL statements
could be passed to $sth->prepare(). For example:
# $user is from an untrusted source and is tainted.
$user = get_user_data_from_the_outside_world;
$sth = $dbh->prepare('DELETE FROM Users WHERE User = $user');
Looks innocent enough... but what if $user was the string "1 OR User LIKE
'%'". You just blew away all your users. Hope you have backups.
Ima::DBI turns on the DBI->connect Taint attribute so that all DBI
methods (except execute()) will no longer accept tainted data.
See L<DBI/Taint> for details.
=item * Taints returned data
Databases should be like any other system call. It's the scary Outside
World, thus it should be tainted. Simple. Ima::DBI turns on DBI's Taint
attribute on each connection. This feature is overridable by passing
your own Taint attribute to set_db as normal for DBI. See L<DBI/Taint>
for details.
=item * Encapsulation of some of the more repetitive bits of everyday DBI usage
I get lazy a lot and I forget to do things I really should, like using
bind_cols(), or rigorous error checking. Ima::DBI does some of this
stuff automatically, other times it just makes it more convenient.
=item * Encapsulation of DBI's cache system
DBI's automatic handle caching system is relatively new, and some people
aren't aware of its use. Ima::DBI uses it automatically, so you don't
have to worry about it. (It even makes it a bit more efficient)
=item * Sharing of database and sql information amongst inherited classes
Any SQL statements and connections created by a class are available to
its children via normal method inheritance.
=item * Guarantees one connection per program.
One program, one database connection (per database user). One program,
one prepared statement handle (per statement, per database user).
That's what Ima::DBI enforces. Extremely handy in persistant environments
(servers, daemons, mod_perl, FastCGI, etc...)
=item * Encourages use of bind parameters and columns
Bind parameters are safer and more efficient than embedding the column
information straight into the SQL statement. Bind columns are more
efficient than normal fetching. Ima::DBI pretty much requires the usage
of the former, and eases the use of the latter.
=back
=head2 Why shouldn't I use this thing.
=over 4
=item * It's all about OO
Although it is possible to use Ima::DBI as a stand-alone module as
part of a function-oriented design, its generally not to be used
unless integrated into an object-oriented design.
=item * Overkill for small programs
=item * Overkill for programs with only one or two SQL statements
Its up to you whether the trouble of setting up a class and jumping
through the necessary Ima::DBI hoops is worth it for small programs.
To me, it takes just as much time to set up an Ima::DBI subclass as it
would to access DBI without it... but then again I wrote the module.
YMMV.
=item * Overkill for programs that only use their SQL statements once
Ima::DBI's caching might prove to be an unecessary performance hog if
you never use the same SQL statement twice. Not sure, I haven't
looked into it.
=back
=head1 USAGE
The basic steps to "DBIing" a class are:
=over 4
=item 1
Inherit from Ima::DBI
=item 2
Set up and name all your database connections via set_db()
=item 3
Set up and name all your SQL statements via set_sql()
=item 4
Use sql_* to retrieve your statement handles ($sth) as needed and db_*
to retreive database handles ($dbh).
=back
Have a look at L<EXAMPLE> below.
=head1 TAINTING
Ima::DBI, by default, uses DBI's Taint flag on all connections.
This means that Ima::DBI methods do not accept tainted data, and that all
data fetched from the database will be tainted. This may be different
from the DBI behavior you're used to. See L<DBI/Taint> for details.
=head1 Class Methods
=head2 set_db
Foo->set_db($db_name, $data_source, $user, $password);
Foo->set_db($db_name, $data_source, $user, $password, \%attr);
This method is used in place of DBI->connect to create your database
handles. It sets up a new DBI database handle associated to $db_name.
All other arguments are passed through to DBI->connect_cached.
A new method is created for each db you setup. This new method is called
"db_$db_name"... so, for example, Foo->set_db("foo", ...) will create
a method called "db_foo()". (Spaces in $db_name will be translated into
underscores: '_')
%attr is combined with a set of defaults (RaiseError => 1, AutoCommit
=> 0, PrintError => 0, Taint => 1). This is a better default IMHO,
however it does give databases without transactions (such as MySQL when
used with the default MyISAM table type) a hard time. Be sure to turn
AutoCommit back on if your database does not support transactions.
The actual database handle creation (and thus the database connection)
is held off until a prepare is attempted with this handle.
=cut
sub _croak { my $self = shift; require Carp; Carp::croak(@_) }
sub set_db {
my $class = shift;
my $db_name = shift or $class->_croak("Need a db name");
$db_name =~ s/\s/_/g;
my $data_source = shift or $class->_croak("Need a data source");
my $user = shift || "";
my $password = shift || "";
my $attr = shift || {};
ref $attr eq 'HASH' or $class->_croak("$attr must be a hash reference");
$attr = $class->_add_default_attributes($attr);
$class->_remember_handle($db_name);
no strict 'refs';
*{ $class . "::db_$db_name" } =
$class->_mk_db_closure($data_source, $user, $password, $attr);
return 1;
}
sub _add_default_attributes {
my ($class, $user_attr) = @_;
my %attr = $class->_default_attributes;
@attr{ keys %$user_attr } = values %$user_attr;
return \%attr;
}
sub _default_attributes {
(
RaiseError => 1,
AutoCommit => 0,
PrintError => 0,
Taint => 1,
RootClass => "DBIx::ContextualFetch"
);
}
sub _remember_handle {
my ($class, $db) = @_;
my $handles = $class->__Database_Names || [];
push @$handles, $db;
$class->__Database_Names($handles);
}
sub _mk_db_closure {
my ($class, $dsn, $user, $pass, $attr) = @_;
$attr ||= {};
my $dbh;
my $process_id = $$;
return sub {
# set the PID in a private cache key to prevent us
# from sharing one with the parent after fork. This
# is better than disconnecting the existing $dbh since
# the parent may still need the connection open. Note
# that forking code also needs to set InactiveDestroy
# on all open handles in the child or the connection
# will be broken during DESTROY.
$attr->{private_cache_key_pid} = $$;
# reopen if this is a new process or if the connection
# is bad
if ($process_id != $$ or
not ($dbh && $dbh->FETCH('Active') && $dbh->ping)) {
$dbh = DBI->connect_cached($dsn, $user, $pass, $attr);
$process_id = $$;
}
return $dbh;
};
}
=head2 set_sql
Foo->set_sql($sql_name, $statement, $db_name);
Foo->set_sql($sql_name, $statement, $db_name, $cache);
This method is used in place of DBI->prepare to create your statement
handles. It sets up a new statement handle associated to $sql_name using
the database connection associated with $db_name. $statement is passed
through to either DBI->prepare or DBI->prepare_cached (depending on
$cache) to create the statement handle.
If $cache is true or isn't given, then prepare_cached() will be used to
prepare the statement handle and it will be cached. If $cache is false
then a normal prepare() will be used and the statement handle will be
recompiled on every sql_*() call. If you have a statement which changes
a lot or is used very infrequently you might not want it cached.
A new method is created for each statement you set up. This new method
is "sql_$sql_name"... so, as with set_db(), Foo->set_sql("bar", ...,
"foo"); will create a method called "sql_bar()" which uses the database
connection from "db_foo()". Again, spaces in $sql_name will be translated
into underscores ('_').
The actual statement handle creation is held off until sql_* is first
called on this name.
=cut
sub set_sql {
my ($class, $sql_name, $statement, $db_name, $cache) = @_;
$cache = 1 unless defined $cache;
# ------------------------- sql_* closure ----------------------- #
my $db_meth = $db_name;
$db_meth =~ s/\s/_/g;
$db_meth = "db_$db_meth";
(my $sql_meth = $sql_name) =~ s/\s/_/g;
$sql_meth = "sql_$sql_meth";
# Remember the name of this handle for the class.
my $handles = $class->__Statement_Names || [];
push @$handles, $sql_name;
$class->__Statement_Names($handles);
no strict 'refs';
*{ $class . "::$sql_meth" } =
$class->_mk_sql_closure($sql_name, $statement, $db_meth, $cache);
return 1;
}
sub _mk_sql_closure {
my ($class, $sql_name, $statement, $db_meth, $cache) = @_;
return sub {
my $class = shift;
my $dbh = $class->$db_meth();
# Everything must pass through sprintf, even if @_ is empty.
# This is to do proper '%%' translation.
my $sql = $class->transform_sql($statement => @_);
return $cache
? $dbh->prepare_cached($sql)
: $dbh->prepare($sql);
};
}
=head2 transform_sql
To make up for the limitations of bind parameters, $statement can contain
sprintf() style formatting (ie. %s and such) to allow dynamically
generated SQL statements (so to get a real percent sign, use '%%').
The translation of the SQL happens in transform_sql(), which can be
overridden to do more complex transformations. See L<Class::DBI> for an
example.
=cut
sub transform_sql {
my ($class, $sql, @args) = @_;
return sprintf $sql, @args;
}
=head2 db_names / db_handles
my @database_names = Foo->db_names;
my @database_handles = Foo->db_handles;
my @database_handles = Foo->db_handles(@db_names);
Returns a list of the database handles set up for this class using
set_db(). This includes all inherited handles.
db_names() simply returns the name of the handle, from which it is
possible to access it by converting it to a method name and calling
that db method...
my @db_names = Foo->db_names;
my $db_meth = 'db_'.$db_names[0];
my $dbh = $foo->$db_meth;
Icky, eh? Fortunately, db_handles() does this for you and returns a
list of database handles in the same order as db_names(). B<Use this
sparingly> as it will connect you to the database if you weren't
already connected.
If given @db_names, db_handles() will return only the handles for
those connections.
These both work as either class or object methods.
=cut
sub db_names { @{ $_[0]->__Database_Names || [] } }
sub db_handles {
my ($self, @db_names) = @_;
@db_names = $self->db_names unless @db_names;
return map $self->$_(), map "db_$_", @db_names;
}
=head2 sql_names
my @statement_names = Foo->sql_names;
Similar to db_names() this returns the names of all SQL statements set
up for this class using set_sql(), inherited or otherwise.
There is no corresponding sql_handles() because we can't know what
arguments to pass in.
=cut
sub sql_names { @{ $_[0]->__Statement_Names || [] } }
=head1 Object Methods
=head2 db_*
$dbh = $obj->db_*;
This is how you directly access a database handle you set up with set_db.
The actual particular method name is derived from what you told set_db.
db_* will handle all the issues of making sure you're already
connected to the database.
=head2 sql_*
$sth = $obj->sql_*;
$sth = $obj->sql_*(@sql_pieces);
sql_*() is a catch-all name for the methods you set up with set_sql().
For instance, if you did:
Foo->set_sql('GetAllFoo', 'Select * From Foo', 'SomeDb');
you'd run that statement with sql_GetAllFoo().
sql_* will handle all the issues of making sure the database is
already connected, and the statement handle is prepared. It returns a
prepared statement handle for you to use. (You're expected to
execute() it)
If sql_*() is given a list of @sql_pieces it will use them to fill in
your statement, assuming you have sprintf() formatting tags in your
statement. For example:
Foo->set_sql('GetTable', 'Select * From %s', 'Things');
# Assuming we have created an object... this will prepare the
# statement 'Select * From Bar'
$sth = $obj->sql_Search('Bar');
Be B<very careful> with what you feed this function. It cannot
do any quoting or escaping for you, so it is totally up to you
to take care of that. Fortunately if you have tainting on you
will be spared the worst.
It is recommended you only use this in cases where bind parameters
will not work.
=head2 DBIwarn
$obj->DBIwarn($what, $doing);
Produces a useful error for exceptions with DBI.
B<I'm not particularly happy with this interface>
Most useful like this:
eval {
$self->sql_Something->execute($self->{ID}, @stuff);
};
if($@) {
$self->DBIwarn($self->{ID}, 'Something');
return;
}
=cut
sub DBIwarn {
my ($self, $thing, $doing) = @_;
my $errstr = "Failure while doing '$doing' with '$thing'\n";
$errstr .= $@ if $@;
require Carp;
Carp::carp $errstr;
return 1;
}
=head1 Modified database handle methods
Ima::DBI makes some of the methods available to your object that are
normally only available via the database handle. In addition, it
spices up the API a bit.
=head2 commit
$rc = $obj->commit;
$rc = $obj->commit(@db_names);
Derived from $dbh->commit() and basically does the same thing.
If called with no arguments, it causes commit() to be called on all
database handles associated with $obj. Otherwise it commits all
database handles whose names are listed in @db_names.
Alternatively, you may like to do: $rc = $obj->db_Name->commit;
If all the commits succeeded it returns true, false otherwise.
=cut
sub commit {
my ($self, @db_names) = @_;
return grep(!$_, map $_->commit, $self->db_handles(@db_names)) ? 0 : 1;
}
=head2 rollback
$rc = $obj->rollback;
$rc = $obj->rollback(@db_names);
Derived from $dbh->rollback, this acts just like Ima::DBI->commit,
except that it calls rollback().
Alternatively, you may like to do: $rc = $obj->db_Name->rollback;
If all the rollbacks succeeded it returns true, false otherwise.
=cut
sub rollback {
my ($self, @db_names) = @_;
return grep(!$_, map $_->rollback, $self->db_handles(@db_names)) ? 0 : 1;
}
=head1 EXAMPLE
package Foo;
use base qw(Ima::DBI);
# Set up database connections (but don't connect yet)
Foo->set_db('Users', 'dbi:Oracle:Foo', 'admin', 'passwd');
Foo->set_db('Customers', 'dbi:Oracle:Foo', 'Staff', 'passwd');
# Set up SQL statements to be used through out the program.
Foo->set_sql('FindUser', <<"SQL", 'Users');
SELECT *
FROM Users
WHERE Name LIKE ?
SQL
Foo->set_sql('ChangeLanguage', <<"SQL", 'Customers');
UPDATE Customers
SET Language = ?
WHERE Country = ?
SQL
# rest of the class as usual.
package main;
$obj = Foo->new;
eval {
# Does connect & prepare
my $sth = $obj->sql_FindUser;
# bind_params, execute & bind_columns
$sth->execute(['Likmi%'], [\($name)]);
while( $sth->fetch ) {
print $name;
}
# Uses cached database and statement handles
$sth = $obj->sql_FindUser;
# bind_params & execute.
$sth->execute('%Hock');
@names = $sth->fetchall;
# connects, prepares
$rows_altered = $obj->sql_ChangeLanguage->execute(qw(es_MX mx));
};
unless ($@) {
# Everything went okay, commit the changes to the customers.
$obj->commit('Customers');
}
else {
$obj->rollback('Customers');
warn "DBI failure: $@";
}
=head1 USE WITH MOD_PERL, FASTCGI, ETC.
To help with use in forking environments, Ima::DBI database handles keep
track of the PID of the process they were openend under. If they notice
a change (because you forked a new process), a new handle will be opened
in the new process. This prevents a common problem seen in environments
like mod_perl where people would open a handle in the parent process and
then run into trouble when they try to use it from a child process.
Because Ima::DBI handles keeping database connections persistent and
prevents problems with handles openend before forking, it is not
necessary to use Apache::DBI when using Ima::DBI. However, there is
one feature of Apache::DBI which you will need in a mod_perl or FastCGI
environment, and that's the automatic rollback it does at the end of each
request. This rollback provides safety from transactions left hanging
when some perl code dies -- a serious problem which could grind your
database to a halt with stale locks.
To replace this feature on your own under mod_perl, you can add something
like this in a handler at any phase of the request:
$r->push_handlers(PerlCleanupHandler => sub {
MyImaDBI->rollback();
});
Here C<MyImaDBI> is your subclass of Ima::DBI. You could also make this
into an actual module and set the PerlCleanupHandler from your httpd.conf.
A similar approach should work in any long-running environment which has
a hook for running some code at the end of each request.
=head1 TODO, Caveat, BUGS, etc....
=over 4
=item I seriously doubt that it's thread safe.
You can bet cupcackes to sno-cones that much havoc will be wrought if
Ima::DBI is used in a threaded Perl.
=item Should make use of private_* handle method to store information
=item The docs stink.
The docs were originally written when I didn't have a good handle on
the module and how it will be used in practical cases. I need to
rewrite the docs from the ground up.
=item Need to add debugging hooks.
The thing which immediately comes to mind is a Verbose flag to print
out SQL statements as they are made as well as mention when database
connections are made, etc...
=back
=head1 MAINTAINERS
Tony Bowden <tony@tmtm.com> and Perrin Harkins <perrin@elem.com>
=head1 ORIGINAL AUTHOR
Michael G Schwern <schwern@pobox.com>
=head1 LICENSE
This module is free software. You may distribute under the same terms
as Perl itself. IT COMES WITHOUT WARRANTY OF ANY KIND.
=head1 THANKS MUCHLY
Tim Bunce, for enduring many DBI questions and adding Taint,
prepare_cached and connect_cached methods to DBI, simplifying this
greatly!
Arena Networks, for effectively paying for Mike to write most of this
module.
=head1 SEE ALSO
L<DBI>.
You may also choose to check out L<Class::DBI> which hides most of this
from view.
=cut
return 1001001;
Ima-DBI-0.35/t/ 0000755 0000000 0000000 00000000000 10633061073 0013003 5 ustar 00root root 0000000 0000000 Ima-DBI-0.35/t/DBI.t 0000644 0000000 0000000 00000007151 10633061073 0013572 0 ustar 00root root 0000000 0000000 package My::DBI;
$|++;
use strict;
use base 'Ima::DBI';
use Test::More tests => 27;
sub new { return bless {}; }
# Test set_db
__PACKAGE__->set_db('test1', 'dbi:ExampleP:', '', '',
{ AutoCommit => 1, Taint => 0 });
__PACKAGE__->set_db('test2', 'dbi:ExampleP:', '', '',
{ AutoCommit => 1, foo => 1 });
ok(__PACKAGE__->can('db_test1'), 'set_db("test1")');
ok(__PACKAGE__->can('db_test2'), 'set_db("test2")');
ok eq_array([ sort __PACKAGE__->db_names ], [ sort qw/test1 test2/ ]),
'db_names';
ok eq_array([ sort __PACKAGE__->db_handles ],
[ sort (__PACKAGE__->db_test1, __PACKAGE__->db_test2) ]),
'db_handles';
# Test set_sql
__PACKAGE__->set_sql('test1', 'select foo from bar where yar = ?', 'test1');
__PACKAGE__->set_sql('test2', 'select mode,size,name from ?', 'test2');
__PACKAGE__->set_sql('test3', 'select %s from ?', 'test1');
__PACKAGE__->set_sql('test4', 'select %s from ?', 'test1', 0);
__PACKAGE__->set_sql('test5', 'select mode,size,name from ?', 'test1');
for (1 .. 5) {
ok __PACKAGE__->can("sql_test$_"), "SQL for test$_ set up";
}
ok eq_array(
[ sort __PACKAGE__->sql_names ],
[ sort qw/test1 test2 test3 test4 test5/ ]
),
'sql_names';
my $obj = My::DBI->new;
# Test sql_*
use Cwd;
my $dir = cwd();
my ($col0, $col1, $col2);
# Test execute & fetch
{
my $sth = $obj->sql_test2;
isa_ok $sth, 'DBIx::ContextualFetch::st';
ok $sth->{Taint}, "Taint mode on queries in db1";
ok $sth->execute([$dir], [ \($col0, $col1, $col2) ]), "Execute";
my @row_a = $sth->fetch;
ok eq_array(\@row_a, [ ($col0, $col1, $col2) ]), "Values OK";
$sth->finish;
}
# Test fetch_hash
{
my $sth = $obj->sql_test2;
$sth->execute($dir);
my %row_hash = $sth->fetch_hash;
is keys %row_hash, 3, "3 values fetched back in hash";
eval { 1 while (my %row = $sth->fetch_hash); };
ok(!$@, "fetch_hash() doesn't blow up at the end of its fetching");
}
# Test fetch_row/fetch_val/fetch_col
{
my $sth = $obj->sql_test2;
my @row = $sth->select_row($dir);
is @row, 3, "select_row got 3 values";
my $val = $sth->select_val($dir);
is $val, $row[0], "select_val is first entry in row";
my @col = $sth->select_col($dir);
is $val, $col[0], "... and first entry in column";
}
# Test dynamic SQL generation.
{
my $sth = $obj->sql_test3(join ',', qw/mode size name/);
ok !$sth->{Taint}, "Taint mode off for queries in db2";
my $new_sth = $obj->sql_test3(join ',', qw/mode size name/);
is $new_sth, $sth, 'Cached handles';
# TODO: {
# local $TODO = "Clear sth cache";
# $sth->clear_cache;
# my $another_sth = $obj->sql_test3(join ', ', qw/mode size name/);
# isnt $another_sth, $sth, 'Get a new sth after clearing cache';
# }
$new_sth = $obj->sql_test3(join ', ', qw/mode name/);
isnt $new_sth, $sth, 'redefined statement';
$sth = $obj->sql_test4(join ',', qw/mode size name/);
isa_ok $sth, 'DBIx::ContextualFetch::st';
$new_sth = $obj->sql_test4(join ',', qw/mode size name/);
isa_ok $sth, 'DBIx::ContextualFetch::st';
isnt $new_sth, $sth, 'cached handles off';
}
{
my $dbh = __PACKAGE__->db_test1;
my $sth5 = __PACKAGE__->sql_test5;
my $new_dbh = __PACKAGE__->db_test1;
is $dbh, $new_dbh, 'dbh handle caching';
# TODO: {
# local $TODO = "Clear dbh cache";
# $dbh->clear_cache;
# my $another_dbh = __PACKAGE__->db_test1;
# isnt $another_dbh, $dbh, '$dbh->clear_cache';
#
# my $new_sth5 = __PACKAGE__->sql_test5;
# isnt $sth5, $new_sth5, ' handles flushed, too';
# }
}
eval { Ima::DBI->i_dont_exist; };
# There's some odd precedence problem trying to pass this all at once.
my $ok = $@ =~ /^Can\'t locate object method "i_dont_exist" via package/;
ok $ok, 'Accidental AutoLoader inheritance blocked';
Ima-DBI-0.35/t/pod-coverage.t 0000644 0000000 0000000 00000000241 10633061073 0015540 0 ustar 00root root 0000000 0000000 use Test::More;
eval "use Test::Pod::Coverage 1.00";
plan skip_all => "Test::Pod::Coverage 1.00 required for testing POD coverage" if $@;
all_pod_coverage_ok();
Ima-DBI-0.35/t/pod.t 0000644 0000000 0000000 00000000201 10633061073 0013743 0 ustar 00root root 0000000 0000000 use Test::More;
eval "use Test::Pod 1.00";
plan skip_all => "Test::Pod 1.00 required for testing POD" if $@;
all_pod_files_ok();