#19618 closed feature request (wontfix)
Extending the Transient API outside of the wp_options table
Reported by: | VicePrez | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | trivial | Version: | |
Component: | Cache API | Keywords: | |
Focuses: | Cc: |
Description
I was wondering if the dev team would consider extending the Transients API outside of the wp_options
table to a user-specified table.
I've managed to mimic, to a certain extent, the *_transient
and *_option
family of functions with my own functions, and sql queries, to check, update, insert, and delete sql data. I find myself at awe, when I realize I could have easily achieved the same thing with a few lines of code using the Transients API.
Needless to say, this could benefit a lot of plugin authors who resort to creating their own tables to store temporary data. The creation of sql tables, should be left up to the plugins author, but in my opinion, it's better to stay in house and use the Transients API to insert, and remove data instead of having to build something from scratch.
Change History (3)
#1
@
13 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
#2
follow-up:
↓ 3
@
13 years ago
You could create your own cache backend that puts the transient group into a separate table.
#3
in reply to:
↑ 2
@
13 years ago
Replying to scribu:
Thanks for the detailed response scribu. Just had to throw out there, to see if it was at all possible/practical.
Replying to ryan:
You could create your own cache backend that puts the transient group into a separate table.
That seems really promising, I sort of have an idea of how to tackle it, but I've got a little bit more reading to do before I can dive into it. It's a bit complicated because I've got data which needs to last up to a week to act as a backup for the more temporary data (under 24 hours). Thanks for the input ryan.
My apologies for taking from your time guys. I appreciate the help.
For the transients API, wp_options is just a fallback. The primary storage is a persistent cache backend, such as Memcache. Therefore, it doesn't make any sense to "extend the transients API" to other tables.
Since we already have the Transients API, I don't see why plugin authors would create their own tables for temporary data, unless they had a specific need, in which case we couldn't provide a generic API anyway.