Description: ------------ I noticed Translation2 caused 481 queries through MDB2, even though I used CacheMemory as a decorator. Investigating, I noticed that CacheMemory::get() prefetched pages using CacheMemory::getPageRaw(), rather than CacheMemory::getPage(). This may previously have been reported in Bug #3914, but still doesn't work as one would expect.

As said in the bug report you already found, get() calls getRawPage() and not getPage() because otherwise it would not work with parameter replacement. Do you have any suggestion on how to deal with both cases?

Can you clarify the problem? The page is loaded before parameters for substitution are available?

1) you call setParams() with some parameters 2) you call getPage() => it gets cached, the parameters are replaced 3) you call setParams() with some other parameters 4) you call getPage() Now, if the page was cached WITH the replaced parameters, you cannot replace the new parameters. Hence, in the cache decorator getRawPage() is called to make replacement of new parameters possible. Does it make sense?

Yes. However, the current evasion of the problem breaks caching for both get() and getRaw(). Looking at http://cvs.php.net/viewvc.cgi/pear/Translation2/Decorator/CacheMemory.php? revision=1.12&view=markup, 1) getRaw() prefetches pages into $this->rawData using getRawPage(), but looks for prefetched strings in $this->data, where it never finds any, and thus resorts to $this->translation2->getRaw() 2) get() prefetches pages into $this->rawData using getRawPage(), but looks for prefetched string in $this->data, where it never finds any, and thus resorts to $this->translation2->get() So, every string is fetched from storage, one at a time, nullifying performance benefits and effectively defying its purpose. At least, I would expect to have a working getRaw(). Could we change that to look in $this->rawData for strings instead? As for get(), how about letting getPage() fetch the raw page into $this- >rawData, and save a parameterized copy in $this->data. Additionally, override setParams() to re-parameterize the page (from the cached rawPage) when parameters change. What do you think?

> Additionally, override setParams() to re-parameterize > the page (from the cached rawPage) when parameters change. excellent suggestion, I hadn't thought of that. I will fix the decorator ASAP. Thanks!

An alternative, simpler solution: Use just-in-time parameterization: Let both get() and getRaw() fetch the raw data into $this->rawPage, with no whole-page parameterization. And let get() replace parameters in each string just before it is returned.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.