clayton cottingham wrote:
> 
> Greg Cope wrote:
> >
> > Jason Liu wrote:
> > >
> > > Is Apache::DBI absolutely necessary if you want to establish persistent
> > > database connection per child?
> >
> > No you can write your own (its open source remember ;-) but why bother -
> > standing on the shoulders of giants etc ....
> >

> i usually use something that does all the basic statement handling and
> db connect strings
> 
> then i can just
> use PGForm; #my module to go to Pg
> PGform($db,$user,$password,$sqlstatement);
> 
> and
> if a select returns a array of arrays
> 
> else if insert update delete etc returns ok or error

I agree with Clayton about wrappers, but for slightly different reasons:
Apache::DBI is, as far as I know, dangerous, and people rarely seem to
warn of this.

It's dangerous because:
(a) Although it rolls back any transactions automatically, it may not
deal with other persistant
    state on the handle. (Does it clear MySQL table locks, for
instance?). Other settings, such
    as the lock timeout (SQL: "SET LOCK MODE TO WAIT nnn") or isolation
levels, will also persist.
    A one-shot script may simply set them without thinking about what
happens if they persist.
    Even something written for mod-Perl would have to set them all back
to their previous values,
    and catch its own errors in an eval {}, to avoid unpredictable
things happening in case of errors.

(b) Presumably, what were previously separate transactions on the same
database on different handles
    can become entangled:

    TX1: BEGIN WORK
    TX2: BEGIN WORK
    TX1: INSERT A
    TX2: COMMIT
    TX1: INSERT B

... this would probably cause either fatal errors, or very strange
things to happen.

(a) would be v. hard to avoid without tracking whatever state is used in
your database & application,
    which is where a wrapper comes in.

(b) could be trapped by Apache::DBI refusing to give out two copies of
the same DBH at the same
    time. AS FAR AS I KNOW it doesn't do this.

Cheers

--
Tim Sweetman
A L Digital
---- moving sideways --->

Reply via email to