Consider cache "table"

[Elrond]

Currently, computed (processed) data is stored alongside "original"
data in the database. Most notable example are comments and the
rendered html for them.

There are various reasons for not storing them at the same place:


-  If the options for processing (the created html) changes, a
   migration must be added to convert all existent entries. Or if the
   user changes the options, they have to let every entry be updated.
   Think of large installations! With a cache style setup, one simply
   drops the cache and it will be recreated as needed.
-  It's cleaner layout of the db.
-  Also maybe an option for backup: Many people only want the
   "original" stuff in the backup, as everything else can be
   regenerated as needed.

An alternative is to drop the pre-rendered stuff from the db and
create it "on the fly" as needed.
Or cache it in some (beaker?) memory cache.

[Caleb Davis]

+1! This is where tag clouds would go

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/456 .
Relations:
#183: blocks, #212: blocked

[Christopher Allan Webber]

This is the "longcache" system, right?

Elrond, do you think this still applies post-SQL? Do you imagine we'd just use a json field?