In general when Drupal sets a cache item it sets an 'expired' attribute containing the timestamp when the cache will expire (that is if the cache is time based). If the cache is permanent it sets -1 instead.
Search API sets the cache item using only the lifespan which means it will not be a timestamp. If it is not a timestamp when it is checked to be valid like this $cache->expire >= REQUEST_TIME it always return false. Which means that when we use search api specific cache we do not benefit from cache (only if we have permanent cache).
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 2791691-6--views_cache_lifespan.patch | 1.08 KB | drunken monkey |
Comments
Comment #2
anemes commentedComment #3
anemes commentedComment #4
anemes commentedComment #5
anemes commentedComment #6
drunken monkeyThanks for reporting this issue!
Seems like you're right, looking at the parent method it's obvious we messed up there.
Your patch is missing an import for
Cache, but otherwise it seems fine. However, I think we can make it a bit cleaner, still.Please see my attached revision and tell me what you think!
PS: It seems you (like many others – it's really easy to misinterpret) are confused by the "Issue tags" field. As the guidelines state, they aren't meant for free text tags related to the issue, but only for specific categorization purposes, usually by module maintainers.
So, if you aren't sure your current usage is correct, please just leave the field empty.
Comment #7
anemes commentedYour patch looks good, thanks. Regarding the Issue tags field, I didn't know it was for the maintainers.
Comment #8
anemes commentedComment #10
drunken monkeyThanks for testing/reviewing!
Committed.
Thanks again for your work here!