Re: Statement handle side effects of swap_inner_handle?

On Thu, Jan 26, 2006 at 02:33:21PM -0500, Steven Lembark wrote:
>
> >> The only thing this doesn't pull across that I can think
> >> of is the current row state of each handle
> >
> > You could use $sth->rows and fetch to the same row count
> > (but there's no guarantee you'll be getting the same values).
>
> Artistic Opinion: Would reconnecting the damaged handle
> and keep it usable with an appropriate error then loosing
> the transaction (and letting the caller deal with it
> as an exception) seem reasonable?

Yes. That would possibly suffice is all code gets its statement handles
via prepare_cached(). But then if all code used prepare_cached() and
connect_cached() then you wouldn't need to go down this road at all :)

> > ParamValues and ParamTypes gives you a way to redo bind_param().
> > But there's no equivalent for bind_param_inout(), nor for bind_columns.
> >
> > Umm, bind_columns is probably do-able if the DBI gave you a way to
> > access the current row array. Then you could just bind the new columns
> > to the old ones.
>
> Any real odds?

Odds?

> >> Aside: How likely to change is dbh->clone as of 1.50?
> >>
> >> The "clone" method was added in DBI 1.33. It is very new and likely
> >> to change.
> >
> > The more widely it's used the less likely it is to change :)
> >
> > The 'big issue' is how to deal with attribute values that have changed
> > since the $dbh was created.
>
> Q: Which ones does clone use now?

See the docs and then the code...

Tim.
.