|
Posted by Dean Arnold on February 20, 2008, 7:01 pm
Please log in for more thread options
mapeck65@gmail.com wrote:
> Looking for comments on the name, as well as the function of this
> module proposal. This will be my first public module submission, of a
> module I have developed and used privately for a few months. The
> intention of the module is to provide a FIFO queue for execution of
> SQL statements, providing a fault-tolerant, abstraction of the DBI.
> During times of lost database connectivity, statements will be queued
> while the SQL::QueryQueue object tries to reconnect. Once a
> connection has been reestablished, the queue will resume processing.
>
> SYNOPSIS:
>
> use SQL::QueryQueue;
> ...
> my $queue = SQL::QueryQueue->instance($db_dsn, $db_user_id,
> $db_password);
> my $sql = qq { update test set ip = '209.197.123.153' where domain
> = ?};
> $queue->submit_job($sql, 'perlmonks.org');
> ...
> # in another sub somewhere in your program...
> my $q = SQL::QueryQueue->instance();
> my $sql = qq{ select * from test where ip like '209.%' };
> my $array_ref = $q->submit_job($sql);
> foreach my $row (@$array_ref) {
> print join ', ', @$row, "\n";
> }
>
> The SQL::QueryQueue object inherits from Class::Singleton and depends
> on DBI. The current implementation also depends on Log::Log4perl and
> Linuga::EN::Numbers::Ordinate, though these dependencies could be
> removed.
>
> Any comments & suggestions are greatly appreciated.
>
> Michael Peck
> mpeck [at] pobox.com
Might this be better applied via a DBI subclass (DBIx::QueryQueue) ?
I.e., connect() sets up the queue as well as doing connect,
and prepare/execute/do() route things thru the queue.
Then its all transparent to the rest of the app,
and existing DBI apps (presumably including things like
DBIx::Class, etc.) can just plug it in by changing
"DBI->connect()" to "DBIx::QueryQueue->connect()"
(or via the explicit RootClass connect attribute).
Dean Arnold
Presicient Corp.
| 
XML Sitemap