Opened 11 years ago

Last modified 8 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 Changed 11 years ago by Caleb Davis

+1! This is where tag clouds would go

comment:2 Changed 11 years ago by Will Kahn-Greene

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

comment:3 Changed 10 years ago by Christopher Allan Webber

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 Changed 10 years ago by Christopher Allan Webber

Cc: Elrond added

comment:5 Changed 10 years ago by Christopher Allan Webber

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 Changed 10 years ago by Christopher Allan Webber

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 Changed 9 years ago by Christopher Allan Webber

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 Changed 9 years ago by Christopher Allan Webber

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 Changed 9 years ago by Christopher Allan Webber

Owner: Christopher Allan Webber deleted
Status: in_progressaccepted

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

comment:10 Changed 9 years ago by Elrond

Keywords: longterm added

comment:11 Changed 8 years ago by Ben Sturmfels

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