If you're asking 'how can I pass around a database handle, so I don't have to generate it repeatedly,' there are a couple ways:
The simplest of them would be to create a singleton class, which holds the database handle like so:
package MyStateManagement::DBI::Singleton;
use base qw(DBI);
use DBI;
my $Dbh = undef;
sub connect
{
my $class = shift;
$Dbh ||= DBI->connect( @_ );
return $Dbh;
}
1;
And connect by doing MyStateManagement::DBI::Singleton->connect(); the same way you would connect with DBI. Assuming you use one database handle for the whole package, subsequent connects will use the same connection, and will not regenerate the connect; however, you could change the singleton class to check to see if the connect string was the same, and create some sort of connect hash, if there were multiple connections (or you could just specify the connection by a number, or something of that sort.)
The alternative would be to just pass around your database handle through the subroutines.
Gyan Kapur
gyan.kapur@rhhllp.com
| [reply]
[d/l]
[select] |
Could you give us some code to look at? Persistence is a tricky topic and depends a lot on your particular needs - knowing the details will make for better advice. Also, is your decision not to use existing CPAN modules based on a desire to go with what you already have, or is there a feature that you haven't been able to find?
As a pure guess, I'd say you might want to tie a variable ( so storage is transparent ), or use a persistence class that creates and keeps its own database handle. If you show us your code, we can give more useful suggestions.
Good luck!
| [reply] |
I don't quite get your question. What have you tried that
doesn't work, and what do you know about the nature of the
failure?
A DBI handle is just a reference to an object, stored in a
scalar variable. Pass the scalar variable and you pass the
reference to the object (i.e. the DBI handle). If this
runs contrary to your findings, tell us more about your
findings. | [reply] |
