Closed (fixed)
Project:
Update Status
Version:
5.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
17 May 2007 at 09:59 UTC
Updated:
1 Jun 2007 at 22:01 UTC
Jump to comment: Most recent file
it's a little bit too bad that the huge array of release histories for all installed projects is being stored in the {variables} table. that means we've got to load from the DB and unserialize all that data on every page load. :( it'd be nicer if we made our own table for this, or at least moved this info into {cache} instead of {variables}. i suspect we're going to *need* to do this before this can move into core, so we might as well do it before the 5.x-2.0 release.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | update_status_cache_info.patch_1.txt | 3.04 KB | dww |
| #1 | update_status_cache_info.patch.txt | 2.21 KB | dww |
Comments
Comment #1
dwwthis seems to work nicely, but a review and some more testing would be nice before i commit. i add the info to the cache set to expire in 25 hours, which should work nicely in conjunction with hook_cron() thinking we need to refresh it every 24 hours.
Comment #2
dwwafter brief discussion w/ merlin in IRC, even better patch:
- if the cache has been cleared, we automatically re-fetch on demand
- if the data is stale but hasn't been purged from the cache, we also re-fetch on demand.
- put all this logic in a single _update_status_get_info() helper, so we can tweak it in 1 place
- set it back so that the cache expires at 24 hours, since we don't need to worry about the interaction with hook_cron() anymore.
Comment #3
merlinofchaos commented+1 to this patch. On visual review I approve.
Comment #4
merlinofchaos commented+1 to this patch. On visual review I approve.
Comment #5
dwwcommitted to HEAD.
Comment #6
(not verified) commented