Opened 13 years ago

Last modified 10 years ago

#164 accepted enhancement

Consider cache "table" — at Initial Version

Reported by: Elrond Owned by: Christopher Allan Webber
Priority: trivial Milestone:
Component: programming Keywords: longterm
Cc: Elrond Parent Tickets:

Description

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.



Change History (0)

Note: See TracTickets for help on using tickets.