in reply to Re: DBI prepare_cached VS self cached
in thread DBI prepare_cached VS self cached

I guess what had me thinking it acted like a cache was this statement from the docs. 

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

           Like "prepare" except that the statement handle returned will be
           stored in a hash associated with the $dbh. If another call is made
           to "prepare_cached" with the same $statement and %attr values, then
           the corresponding cached $sth will be returned without contacting
           the database server.
  • Comment on Re: Re: DBI prepare_cached VS self cached

Replies are listed 'Best First'.
Re: Re: Re: DBI prepare_cached VS self cached
by perrin (Chancellor) on Sep 27, 2003 at 20:12 UTC
    Right, the cached statement handle will be returned. Creating a statement handle for an Oracle database normally requires contacting the database server to have it prepare (basically compile and determine an execution plan for) the query. Note that it doesn't say anything about $sth->execute() or fetch() being cached.
[reply]
      Are you sure he wasn't talking about caching the actual prepared statement, versus using the prepare_cached method? I.E. while not caching the data, he can actually store

      $queries{"SELECT .."} = $dbh->prepare("SELECT ..");

      Which is talked about here: http://perl.apache.org/docs/1.0/guide/performance.html#Eliminating_SQL_Statement_Parsing

[reply]
[d/l]
        Yes, quite sure.

        I created a %CACHE with the select statement as the Key and a Hash representing the columns returned as the %CACHE value.

[reply]

In Section Seekers of Perl Wisdom