[wp-trac] [WordPress Trac] #61296: Add "force" parameter to get_option and get_transient

[WordPress Trac]

#61296: Add "force" parameter to get_option and get_transient
-----------------------------------------+-----------------------------
 Reporter:  juvodesign                   |       Owner:  (none)
     Type:  enhancement                  |      Status:  reopened
 Priority:  normal                       |   Milestone:  Future Release
Component:  Options, Meta APIs           |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |     Focuses:  performance
-----------------------------------------+-----------------------------
Changes (by azaozz):

 * focuses:   => performance
 * milestone:  Awaiting Review => Future Release


Comment:

 Replying to [comment:13 juvodesign]:

 > In my scenario B has already fetched the transients at the start of the
 action
 > ...
 > This situation gets worse when you have really long-running processes
 like an importer. The in-memory cache without directly calling
 wp_cache_get("", "", true) will very likely be stale at some point.

 Right, when not using external cache, and the site is large/busy, the
 chance for an option (or transient) to get updated while some slow process
 is running increase. Thinking that would be a pretty rare edge case
 though, large/busy sites generally always use external cache.

 > This happened to me, and I had to create an ugly wrapper

 I don't think a wrapper is such a bad idea, especially if forcing a trip
 to the DB will be only for transients. Whether such wrapper should be in
 WP core or only in plugins that may need it is another question.

 > My personal opinion is that developers using the transient API shouldn't
 need to worry about whether an external cache is being used or not.

 Right. However there is always a chance, albeit very small, of a race
 condition when two processes try to simultaneously read/write the same
 data or the same row in the DB. This is unavoidable afaik, and the
 developers should be aware of it and account for such cases if they use
 very slow running processes.

 > To fix this for transients, there is no need to tackle alloptions as
 transients are never stored as autoload options if I am not mistaken.

 Not exactly. If transient expiration is not set, and they are stored in
 the options table, they seem to be autoloaded:
 https://core.trac.wordpress.org/browser/tags/6.6.1/src/wp-
 includes/option.php#L1516.

 > Nonetheless, the provided patch looks good to me..

 At this point I'm about 50/50 about adding another param to `get_option()`
 and friends.
 - On one side there is a legitimate use case for transients, and maybe for
 all options, when external cache is not used. Seems that use case is
 extremely rare though, and will not be solved completely by forcing
 another trip to the DB.
 - On the other side there is a chance that many plugins would switch to
 forcing these trips to the DB "just in case" which will result in
 (possibly significant) slow-down in some cases. Also I tend to agree with
 @spacedmonkey's comment here:
 https://core.trac.wordpress.org/ticket/37178#comment:7. Adding a `force`
 param to `get_option()` would also mean it may need a `cache_only` param
 too? (Thanks @SergeyBiryukov for the link).

 Going to set this to "future release" pending a review by the performance
 team.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61296#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform