Opened 13 years ago

Last modified 10 years ago

#164 accepted enhancement

Consider cache "table"

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

Description (last modified by Christopher Allan Webber)

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 (11)

comment:1 by Caleb Davis, 13 years ago

+1! This is where tag clouds would go

comment:2 by Will Kahn-Greene, 12 years ago

The original url for this bug was .
#183: blocks, #212: blocked

comment:3 by Christopher Allan Webber, 12 years ago

Description: modified (diff)

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?

comment:4 by Christopher Allan Webber, 12 years ago

Cc: Elrond added

comment:5 by Christopher Allan Webber, 11 years ago

Owner: changed from Christopher Allan Webber to spaetz
Status: acceptedassigned

Note that spaetz has built a tag clouds prototype plugin.

There hasn't been any ticket on this for a while, though I assume there's still interest. Spaetz, I am somewhat curious if you think you could make use of such a thing.

comment:6 by Christopher Allan Webber, 11 years ago

Owner: changed from spaetz to Christopher Allan Webber
Priority: minortrivial

Having talked about it with spaetz this doesn't look like something that would use longcache, it would use normal caching.

This longcache stuff would be more useful if we had a generic way of reprocessing originals. Since we don't have that, this ticket isn't very useful for now. I'm lowering priority to trivial. Once we have reprocessing stuff figured out we can re-raise the priority.

comment:7 by Christopher Allan Webber, 11 years ago

No movement has been made on this yet, but for reference, reprocessing may happen in GSoC/OPW; here's a link to the draft ideas doc

comment:8 by Christopher Allan Webber, 11 years ago

Status: assignedin_progress

Hi! I'm moving this ticket from "assigned" to in_progress per our new workflow. Please update the ticket and let us know if you're still working on this. If you are, super great! If not, we'll remove the claim and move it back to "accepted" in a couple of weeks.


comment:9 by Christopher Allan Webber, 11 years ago

Owner: Christopher Allan Webber removed
Status: in_progressaccepted

I'm unclaiming this because I haven't been doing anything on it for some time.

comment:10 by Elrond, 11 years ago

Keywords: longterm added

comment:11 by Ben Sturmfels, 10 years ago

Type: defectenhancement
Note: See TracTickets for help on using tickets.