Bug #71083 for DBIx-Simple: Accessor for DBIx::Simple::Result statement handle

On Tue Sep 20 06:21:56 2011, DAGOLDEN wrote: Show quoted text
Allowing access to the statement handle breaks the reference management necessary for statement caching so I'm reluctant to exposing it. At least when you violate encapsulation, it's clear to everyone that you're doing something that wasn't part of the plan. Perhaps specific parts of the sth could be delegated explicitly. Which feature of the sth are you using? -- Juerd

On Fri Oct 07 07:06:58 2011, DAGOLDEN wrote: Show quoted text
That's a rather dangerous thing to do with DBIx::Simple. You'll have to be very careful to ensure that the DSBD object will not be longer lived than the DBIx::Simple::Result object. The DSBD has-a sth, but DSR assumes that it is the sole user of the same sth. Once the DSR is destroyed, it puts the sth in a pool for re-use. Executing the same query again while the old sth was still in use means that the original iterator will suddenly return results from the new query. I don't see a way to support this without me receiving many support requests from Perl programmers who don't understand these subtle internal interactions and action-at-a-distance, so I'm rejecting the wishlist item. DSBD is a very complicated way to fetch N rows at a time, by the way. I'd suggest simply doing that manually: sub n_arrays { my ($result, $n) = @_; my @rows; my $row; push @rows, @$row while $n-- and $row = $result->fetch; return @rows; } my $result = $db->query(...); while (my @chunk = n_arrays(100, $result)) { for (@chunk) { ... } } Or do you think DBIx::Simple should have this functionality built-in? while (@chunk = $result->arrays(100)) { ... } while (@chunk = $result->hashes(100)) { ... } while (@chunk = $result->objects(100)) { ... } -- Juerd