Timeline for How to check if result from cache_get() is expired?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 6, 2017 at 15:26 | vote | accept | the | ||
| Feb 11, 2014 at 14:03 | comment | added | Mołot | @MPD better now? | |
| Feb 11, 2014 at 13:58 | history | edited | Mołot | CC BY-SA 3.0 |
added 71 characters in body
|
| Feb 11, 2014 at 13:54 | comment | added | Mołot | @MPD I agree with that. On the other hand there are situations when refreshing data at the exact moment is vital. Especially if it's a government project or other project that must comply with specific laws. Also in case of contests. Probably there are other reasons, too. I assumed that's the case here. | |
| Feb 11, 2014 at 13:43 | comment | added | mpdonadio♦ | I think the big takeaway is that the standard Drupal cache backend exforces a minimum lifetime for non-temporary and non-permanent entries, and not an exact one. In fact, this is stated in the API docs for cache_set: "$expire: One of the following values: ... A Unix timestamp: Indicates that the item should be kept at least until the given time, after which it behaves like CACHE_TEMPORARY." (emphasis mine). In addition, constant pruning of the cache tables will ruin the effectiveness of MySQL query caching, as writes/deletes to a table invalidate all entries in that table. | |
| Feb 11, 2014 at 13:02 | history | edited | Mołot | CC BY-SA 3.0 |
added 308 characters in body
|
| Feb 11, 2014 at 12:54 | history | answered | Mołot | CC BY-SA 3.0 |