[moved to dbi-dev list] On Tue, Oct 16, 2001 at 07:22:11PM -0700, Terrence Brannon wrote: > 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.
Er, actually it's not very clear to me. > ** 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. What's that got to do with subclassing prepare_cached/connect_cached, exactly? Are you trying to add global result-caching by just connecting via a subclass? I've long planned to add result-caching but I don't think it's that simple (in general) and doing it globally (without per-query coding) is probably not what most people want. (I'd expect it to grow out of adding a 'cursor library' and fetch_scroll() [or whatever it's called] method and saving/reusing the data cache that that would need. But that doesn't preclude other approaches.) Tim.
