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 )
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:2 by , 13 years ago
The original url for this bug was http://bugs.foocorp.net/issues/456 .
Relations:
#183: blocks, #212: blocked
comment:3 by , 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 , 12 years ago
Cc: | added |
---|
comment:5 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | accepted → assigned |
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 , 12 years ago
Owner: | changed from | to
---|---|
Priority: | minor → trivial |
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 , 12 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 http://wiki.mediagoblin.org/Feature_Ideas/Reprocessing
comment:8 by , 12 years ago
Status: | assigned → in_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.
Thanks!
comment:9 by , 12 years ago
Owner: | removed |
---|---|
Status: | in_progress → accepted |
I'm unclaiming this because I haven't been doing anything on it for some time.
comment:10 by , 12 years ago
Keywords: | longterm added |
---|
comment:11 by , 10 years ago
Type: | defect → enhancement |
---|