On Sat, 5 Mar 2005, Jonathan Chaffer wrote:
The CCK implementation is going to require a resurrection of node caching,
Yay! [...]
I think we can do a bit better, though. By placing the node cache into a column in the node table, we can grab it at the same time as the node IDs. Then node_load() would look to see if the cache is present in the array presented to it, and if so use that rather than perform any queries at all. 1x query to fetch node IDs and cache for the ten nodes (10 results + deserialize)
So, what you will do is: $result = db_query("SELECT ...."); while ($node = db_fetch_object($result)) { if($node->cache == '') { $node = node_load(array('nid' => $node->nid), 'no cache'); } else { $node = unserialize($node->cache); } } ?
Note that we can use this method with the cache in the cache table as well, but that requires a JOIN using a CONCAT() in the ON clause, which seems risky, and involves direct knowledge of the cache table structure rather than using the cache API anyway.
Any other ideas?
I've never liked the structure of the cache table much. It is a one size fits all thing. Why not split is up? cache_page key: url cache_filter key: md5 of string cache_node key: nid cache_menu key: uid cache_misc key: as now This way we can keep the cache out of the node table (where it does not really belong, IMHO). I am pretty sure that SELECTs from smaller tables will also be faster. The unknown number of entries of the filter cache makes me feel uncomfortable. Cheers, Gerhard