Les Mikesell wrote:
>
> Perrin Harkins wrote:
> >
> > On Fri, 10 Nov 2000, Tim Sweetman wrote:
> > > > Would you be interested in adding support for resetting some of these to
> > > > Apache::DBI? It's pretty easy to do, using PerlCleanupHandler like the
> > > > auto-rollback does. It would be database-specific though, so you'd have
> > > > to find a way for people to explicitly request cleanups.
> > >
> > > I suspect automating via DBI would be a major pain, because you'd have
> > > to be able to identify the "dangerous" changes in state. Probably
> > > requiring SQL to be parsed. :(
> >
> > The current rollback cleanup doesn't parse SQL. It knows that a rollback
> > won't do damage if there are no transactions to be cleaned up, so it's
> > safe to do every time. If there are other things that work this way, you
> > could add them. Probably wouldn't work for things like MySQL table locks
> > though. People will have to do that themselves.
>
> If the backend supports rollback, couldn't you just try that instead
> of the ping method to see if you are still connected and get the
> cleanup as a side effect?
>
>
> > > In principle, you could probably have a ->do_not_reuse method which
> > > could be called before someone does something dangerous. As long as they
> > > remember.
> >
> > But that would also mean no more persistent connection. Maybe that would
> > work if you don't do it very often.
>
> It would be very useful to be able to specify at connect time that
> you don't want a particular connection to be persistent. If you have
> a lot of small databases or some with different user/password
> permissions
> you accumulate too many backend servers - but if you also have one
> or more connections used all the time you don't want to give up
> Apache::DBI. I'm not sure it is worth caching MySQL connections
> on the same host, either since it is so fast to start up. Has
> anyone timed the difference?
>
> Les Mikesell
> [EMAIL PROTECTED]
as far as i can tell the problem here is in the design of the particular
db your connecting to
no one database is going to be architected
in the same way
so providing an abstracted layer to handle this will be a very tough
call
it would be great to see a DBI::persist
or APache::DBI::persist
but it would be hard to implement down the line
to the DBD::***
as each one of those drivers would have to be able to handle the
persistence call in their own way
in some cases this would be an easily handled affair and in others a
real horror show of coding
correct?
