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.
Note:
See TracTickets
for help on using tickets.