Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 2.0.4

Bug #12527 CacheMemory doesn't properly prefetch pages
Submitted: 2007-11-26 12:56 UTC
From: crishoj Assigned: quipo
Status: Closed Package: Translation2 (version 2.0.0RC2)
PHP Version: 5.2.3 OS: Ubuntu
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 12 + 33 = ?

 
 [2007-11-26 12:56 UTC] crishoj (Christian Rishøj)
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.

Comments

 [2007-11-26 13:50 UTC] quipo (Lorenzo Alberton)
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?
 [2007-11-26 14:47 UTC] crishoj (Christian Rishøj)
Can you clarify the problem? The page is loaded before parameters for substitution are available?
 [2007-11-26 15:04 UTC] quipo (Lorenzo Alberton)
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?
 [2007-11-26 20:01 UTC] crishoj (Christian Rishøj)
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?
 [2007-11-28 21:28 UTC] quipo (Lorenzo Alberton)
> 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!
 [2007-11-28 21:36 UTC] crishoj (Christian Rishøj)
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.
 [2007-12-03 07:36 UTC] quipo (Lorenzo Alberton)
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.