[drupal-devel] [drupal-infrastructure] Drupal.org cache
killesreiter at physik.uni-freiburg.de
Thu May 26 21:52:57 UTC 2005
On Thu, 26 May 2005, Gerhard Killesreiter wrote:
> My conclusion is that our cache needs to be more finely grained (right,
> that's not new).
> For example: Comment.module calls cache_clear_all() after a comment has
> been added. Granted, thanks to our block system it can happen that some
> comment (or comment count or "last updated" ...) is displayed on just
> any page. But I'd prefer modules that provide such blocks to build their
> own block cache and invalidate cached pages according to the blocks'
> path settings.
Note that the block caching is not a prereqisite, we could do without.
Most blocks would need per user caches.
> That should not be too difficult. The same should be done
> for blocks that display content based on newly created nodes. Those
> modules should take the cache setting (none, loose, strict) into
> For comment.module that would mean that it only sets variables
> (comment_last_timestamp, comment_last_uid, comment_last_nid,
> comment_last_cid) to new values instead of invalidating the cache.
> forum.module would then check the variable against its own variable
> (forum_last_time_page_rebuilt) and invalidate pages as appropriate.
That's of course nonsense, the modules would need to implement the comment
> Same for tracker and other modules that deal with comments in one way or the
Most modules that display nodes or listings of nodes deal with comments
too by showing "n new comments".
Nodes can be shown in multiple contexts:
/foobar/nid (not often)
I propose that we let comment module clear only /node/nid and let modules
that show nodes in other contexts delete the appropriate pages.
Deleting taxonomy pages might be a bit difficult, haven't checked yet. if
it is too diffcult to find all pages that should be deleted, we could make
it adopt a different policy, ie only delete all taxo pages after the nthe
commment has been committed.
More information about the drupal-devel