>> Q: If the cached kids are stored in $new_dbh, wouldn't I
>> overwrite the statement handles when I performed the
>> $old_dbh->swap_inner_handle( $new_dbh )?
>
> True. If you swap_inner_handle for all ChildHandles then you'll
> automatically deal with CachedKids as well. Simple.
Some good news on the front...
>> 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?
i.e., $dbh->rows is their problem if they know that the
transaction has failed.
> 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?
>> Q: From what I can see, $sth->{Type} doesn't give me
>> enough information to tell if a particular sth
>> is cached or not. Am I missing something?
>
> No. $is_cached = grep { $_ == $sth } values %{$dbh->{CachedKids}};
thanks
> It's not restarting the query-from-hell that worries me, it's the fact
> that rows may have been added or deleted since the first select
> (assuming it is a select statement) so the application may process some
> rows twice and/or miss some rows.
>
> But if you proceed with this then I'd expect your nice CPAN module will
> give people lots of hooks to express what kinds of madness they're
> comfortable with :)
>
>
>> Q: Is there any chance of getting a 'seek' to handle this?
>> It would look sometehing like:
For the moment it seems as though I'd want to just abandon
the transaction and let the user restart it themselves.
There is enough context in it that a "Transaction failed" +
"reconnected" exception would give them enough data to
deal with it appropriately.
>> 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?
thanks for the input.
--
Steven Lembark 85-09 90th Street
Workhorse Computing Woodhaven, NY 11421
[EMAIL PROTECTED] 1 888 359 3508
