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.
all I am saying here is: if a subclass needed to create unique keys into a data cache as a function of prepare and execute arguments, it could not re-use the code the DBI.pm uses to create such unique keys because they are not callable subs in the DBI namespace.
e.g.
package DBI::MySubclass::db;
sub prepare {
my ($dbh, $query, @rest) = @_:
my $prepare_key = DBI::generate_key($query,@rest); ### not currently possible
### but desirable
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.
having spent the last two days tearing my hair out to beat plain DBI with my module DBI::Cache, which sits on top of MLDBM::Sync. In some cases the wallclock seconds would be about the same, but plain dbi requires less user and sys time so it had better results from Benchmark.pm
Also, DBI only uses one memory reference for fetching what could be large result sets. This saves a tremendous amount of memory. On the other hand, I was forced to pull result sets from a Berkeley DB table all into memory at once so that my subclassed fetch could obtain the results.
Sending SQL to database
-----------------------------------
This step may have a bit of network latency and could be slowed if the database had a pool of queries to service at once. In this case a networked version of my module which proxied database requests might be of some use to reduce database load.
SQL Compilation
------------------------
This never seems to take very long. A module like DBIx::Profile might be of use in determining the exact amount of time took.
SQL Execution
---------------------
If the SQL contained a large number of functions it might be of some use to cache it.
Results Fetching
-----------------------
This is a network operation (in general?), but it appears to be quite speedy.
(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.)
If we as a group could spec out what is desired, then I would be happy to implement it.
I attach DBI::Cache, which also entered CPAN as proof-of-concept for this discussion:
http://princepawn.perlmonk.org/domains/semantic-elements.com/cpan/DBI-Cache-1.06.tar.gz
DBI-Cache-1.06.tar.gz