have to run the original query again, and then extract out just the
results for the page the client wants to see.
Seems like some basic design problems there.
Anyway, I'd like to avoid the repeated queries in mod_perl, of course. So,
in the sort term, I was thinking about caching search results
Bill Moseley wrote:
Anyway, I'd like to avoid the repeated queries in mod_perl, of course. So,
in the sort term, I was thinking about caching search results (which is
just a sorted list of file names) using a simple file-system db -- that is,
(carefully) build file names out of the queries
At 10:10 AM 1/8/01 -0800, you wrote:
Bill Moseley wrote:
Anyway, I'd like to avoid the repeated queries in mod_perl, of course. So,
in the sort term, I was thinking about caching search results (which is
just a sorted list of file names) using a simple file-system db
On Mon, 8 Jan 2001, Perrin Harkins wrote:
Bill Moseley wrote:
Anyway, I'd like to avoid the repeated queries in mod_perl, of course. So,
in the sort term, I was thinking about caching search results (which is
just a sorted list of file names) using a simple file-system db
At 02:02 PM 1/8/01 -0800, Sander van Zoest wrote:
On Mon, 8 Jan 2001, Simon Rosenthal wrote:
an RDBMS is not much more trouble to purge, if you have a
time-of-last-update field. And if you're ever going to access your cache
from multiple servers, you definitely don't want to deal with
On Mon, 8 Jan 2001, Simon Rosenthal wrote:
an RDBMS is not much more trouble to purge, if you have a
time-of-last-update field. And if you're ever going to access your cache
from multiple servers, you definitely don't want to deal with locking
issues for DBM and filesystem based
On Mon, Jan 08, 2001 at 10:10:25AM -0800, Perrin Harkins wrote:
Always start with CPAN. Try Tie::FileLRUCache or File::Cache for
starters. A dbm would be fine too, but more trouble to purge old
entries from.
If you find that File::Cache works for you, then you may also want to
check out the
On Mon, 8 Jan 2001, Sander van Zoest wrote:
starters. A dbm would be fine too, but more trouble to purge old entries
from.
You could always have a second dbm file that can keep track of TTL issues
of your data keys, so it would simply be a series of delete calls.
Granted you would have
On Mon, 8 Jan 2001, Simon Rosenthal wrote:
I couldn't see writing a daemon as you suggested offering us any
benefits under those circumstances, given that RDBMS access is built into
Apache::Session.
No, in your case I do not see a reason behind it either. ;-)
Again this shows that it
On Mon, 8 Jan 2001, Perrin Harkins wrote:
On Mon, 8 Jan 2001, Sander van Zoest wrote:
starters. A dbm would be fine too, but more trouble to purge old entries
from.
You could always have a second dbm file that can keep track of TTL issues
of your data keys, so it would simply be a
Hi Guys,
On Mon, 8 Jan 2001, Sander van Zoest wrote:
On Mon, 8 Jan 2001, Perrin Harkins wrote:
On Mon, 8 Jan 2001, Sander van Zoest wrote:
At the risk of getting shot down in flames again,
do you think you could take this off-list guys?
I can't seem to delete the messages as fast as
On Mon, 8 Jan 2001, G.W. Haywood wrote:
At the risk of getting shot down in flames again,
do you think you could take this off-list guys?
I guess this could be moved to the scalable list ([EMAIL PROTECTED]),
or in private since this isn't really on the topic of modperl anymore.
Cheers,
--
12 matches
Mail list logo
