Thought you'd be aware... I can see the bennies for caching result sets, especially when we are talking about compute farms which tend to hammer a database. Just wanted to make sure you weren't trying to reinvent the wheel.
Also, I like Tim's fetch_scroll idea ... > -----Original Message----- > From: Terrence Brannon [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 17, 2001 5:38 PM > To: [EMAIL PROTECTED] > Subject: Re: RFCs: DBI.pm source code and Module proposal > > > > On Wednesday, October 17, 2001, at 03:23 PM, Tim Harsch wrote: > > > I am wondering if Terence has considered using a caching web server... > > Oracle says 9i is so goof at it... not sure I believe that... but still > > it > > sounds like maybe it might help Terence so he doesn't have to roll his > > own > > result caching alroithms if all he is trying to do is performance > > enhance > > many CGIs that hit the database... and if not sorry for the > > distraction... > > That's a good point based on my example ... why cache SQL when you can > cache the page the SQL is generating. > > But webservers was an example. In general, we might be dealing with a > farm of Net::FTPServer processes or Net::Server processes or something > else which will be making parallel equivalent queries from different > processes. > > > > > >> -----Original Message----- > >> From: Tim Bunce [mailto:[EMAIL PROTECTED]] > >> Sent: Wednesday, October 17, 2001 2:48 AM > >> To: Terrence Brannon > >> Cc: [EMAIL PROTECTED] > >> Subject: Re: RFCs: DBI.pm source code and Module proposal > >> > >> > >> [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. > >> > > > >
