Re: [CDBI] Class::DBI vs DBIx::Class

[prev] [thread] [next] [Date index for 2006/01/18]

The prepare_cached() method has a $if_active parameter that lets you
control the behaviour in this case:

=item C<prepare_cached>

  $sth = $dbh->prepare_cached($statement)
  $sth = $dbh->prepare_cached($statement, \%attr)
  $sth = $dbh->prepare_cached($statement, \%attr, $if_active)

Like L</prepare> except that the statement handle returned will be
stored in a hash associated with the C<$dbh>. If another call is made to
C<prepare_cached> with the same C<$statement> and C<%attr> parameter values,
then the corresponding cached C<$sth> will be returned without contacting the
database server.

The C<$if_active> parameter lets you adjust the behaviour if an
already cached statement handle is still Active.  There are several
alternatives:

=over 4

=item B<0>: A warning will be generated, and finish() will be called on
the statement handle before it is returned.  This is the default
behaviour if $if_active is not passed.

=item B<1>: finish() will be called on the statement handle, but the
warning is suppressed.

=item B<2>: Disables any checking.

=item B<3>: The existing active statement handle will be removed from the
cache and a new statement handle prepared and cached in its place.
This is the safest option because it doesn't affect the state of the
old handle, it just removes it from the cache. [Added in DBI 1.40]

=back

 ...

=cut

DBI 1.40 was released in January 2004.

Class::DBI and DBIx::Class (and others) should probably be passing 3
for the $if_active parameter. Set it and forget it.

Tim.

On Tue, Jan 17, 2006 at 03:30:21PM -0500, Perrin Harkins wrote:
> On Tue, 2006-01-17 at 19:00 +0000, Matt S Trout wrote:
> > (2) because the way Ima::DBI uses it, it'll recycle a live sth you'd hung onto
> >     because you weren't finished fetching data from it, thus screwing your app
> >     up quite spectactularly. It only works for CDBI because CDBI fetches all
> >     the data from the sth straight off and throws it away.
> 
> If it works for CDBI then it's probably not a useful point in
> distinguishing between CDBI and DBIx::Class, but for reference, this has
> to do with calling Ima::DBI queries directly, right?  And the issue is
> that if you execute the same query twice with different bind parameters,
> prepare_cached() will reuse the statement handle, and throw away the
> results from the first execution?
> 
> If the data is small, reading it all at once from the first handle would
> be a workaround for this.  If it's too big for that, you'd need to avoid
> prepare_cached.  In that case, you'd have to modify your set_sql call
> for this query to pass the "don't cache me" flag.  I don't think you'd
> need to change any of the other set_sql queries, or modify any
> Class::DBI code because of this.
> 
> - Perrin
> 
> 
> _______________________________________________
> ClassDBI mailing list
> ClassDBI@xxxxx.xxxxxxxxxxxxxxxx.xxx
> http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi

_______________________________________________
ClassDBI mailing list
ClassDBI@xxxxx.xxxxxxxxxxxxxxxx.xxx
http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi