As it stands, neither the algorithm or results of DBI's prepare_cached
and connect_cached key routines are directly useable in subclasses... in
other words the actual key generated is not stored in an attribute of
the handle AND the actual algorithm used to generate these keys is
inlined and not separately callable.
The import of the above observations is that subclasses or container
classes making use of DBI cannot access or easily re-use this cache key
text for it's own purposes.
The module I propose to develop (the second RFC of this email), makes it
clear why this would be useful.
** Module Proposal: Net::DBI or DBI::Cache **
motivation - DBI currently caches statement handles and database handles
within a single process. It does no caching of query results either
within or between processes. Thus if 50 front-end webservers are all hit
with the same query, the best you can do is get a cache of the statement
handle and re-execute. An optimal solution would not only cache the
statement handle but also the query results, alleviating all
un-necessary and repetitive database load.
The most leveraged solution would simply create a stringification of
the execute arguments only and reuse $sth->{private_my_cache_key}.
The caching mechanism would most likely be MLDBM::Sync, but Tie::DB_Lock
also looks possible.
so those are my RFCs... what do you think about my core DBI suggestion
and the module that would result from it?
