Of course, the adapter's state is going to be different after results are retrieved vs before they are retrieved, so this mechanism cannot work. I saved the serialized value of the adapter from the first and second calls to _getInternalCacheId() to a file and did a diff... there are several differences.

The problem is greatly exacerbated if one is using Zend_Db_Profiler. I was using the profiler to determine if the cache was working correctly. Instead, Zend_Paginator was creating a brand new cache entry with a different ID each time every time I reloaded the page. Why? Well, the profiler contains performance information on the queries that have been run thus far. This information will be different from request to request 99.99% of the time. Different content = different serialization = different cacheId.

I would appreciate it if anybody can comment on this bug and perhaps queue up a resolution for the next ZF patch/release.

I am devising a workaround to use in my project and will post it here for the benefit of others who have encountered this problem.

Comments

Posted by julien PAULI (doctorrock83) on 2009-07-23T07:57:12.000+0000

Duplicates #ZF-6989 , even if it gives more informations (will be linked into #ZF-6989)

Posted by julien PAULI (doctorrock83) on 2009-07-23T07:59:44.000+0000

Please, get the patch attached to ZF-6989 and make a use case.
We are actually looking for help to test that in order to provide a patch the better it could be.