Change Details

Backstory: When using Redis as main cache backend (e.g. like mediawiki-vagrant does), various things in MediaWiki (at least ResourceLoader) break in unexpected ways due to $cache->get() returning a string even if an integer was given to $cache->set(). A patch (to just ResourceLoader) to mitigate this was submitted: https://gerrit.wikimedia.org/r/#/c/103407 This works in Wikimedia production because we use Memcached (specifically, a client that preserves the integer type in such a way that doesn't involve php serialise() and still maintains compatibility with native INCR/DECR). I would prefer not to have to deal with this in random parts of the code base where someone ran into a bug when they use an object cache implementation that doesn't properly roundtrip integers. I'm proposing one of two things: * Change our cache interfaces to always return a string, even for clients of Memcached that support maintaining it. This will avoid code from being written like in ResourceLoader from working in one environment and breaking in another. Instead it will never work and thus force us to consistently deal with this after retrieval. We'd get patterns like proposed in https://gerrit.wikimedia.org/r/#/c/103407 in more places, but at least it would become part of expected behaviour and we'd have to do it consistently. * Figure out a way to support integers even for backends like Redis that don't support it fully. Note that though Redis doesn't support storing integers in a way that comes back out, it does have integer operations (e.g. it has native INCR, and it will work on values that look like integers, regardless of whether PHP provided these as integers or strings, they all become strings). -------------------------- **Version**: 1.23.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=56069

Backstory: When using Redis as main cache backend (e.g. like mediawiki-vagrant does), various things in MediaWiki (at least ResourceLoader) break in unexpected ways due to $cache->get() returning a string even if an integer was given to $cache->set(). A patch (to just ResourceLoader) to mitigate this was submitted: https://gerrit.wikimedia.org/r/#/c/103407 This works in Wikimedia production because we use Memcached (specifically, a client that preserves the integer type in such a way that doesn't involve php serialise() and still maintains compatibility with native INCR/DECR). I would prefer not to have to deal with this in random parts of the code base where someone ran into a bug when they use an object cache implementation that doesn't properly roundtrip integers. I'm proposing one of two things: * Change our cache interfaces to always return a string, even for clients of Memcached that support maintaining it. This will avoid code from being written like in ResourceLoader from working in one environment and breaking in another. Instead it will never work and thus force us to consistently deal with this after retrieval. We'd get patterns like proposed in https://gerrit.wikimedia.org/r/#/c/103407 in more places, but at least it would become part of expected behaviour and we'd have to do it consistently. * Figure out a way to support integers even for backends like Redis that don't support it fully. Note that though Redis doesn't support storing integers in a way that comes back out, it does have integer operations (e.g. it has native INCR, and it will work on values that look like integers, regardless of whether PHP provided these as integers or strings, they all become strings). -------------------------- **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=56069

Backstory: When using Redis as main cache backend (e.g. like mediawiki-vagrant does), various things in MediaWiki (at least ResourceLoader) break in unexpected ways due to $cache->get() returning a string even if an integer was given to $cache->set(). A patch (to just ResourceLoader) to mitigate this was submitted: https://gerrit.wikimedia.org/r/#/c/103407 This works in Wikimedia production because we use Memcached (specifically, a client that preserves the integer type in such a way that doesn't involve php serialise() and still maintains compatibility with native INCR/DECR). I would prefer not to have to deal with this in random parts of the code base where someone ran into a bug when they use an object cache implementation that doesn't properly roundtrip integers. I'm proposing one of two things: * Change our cache interfaces to always return a string, even for clients of Memcached that support maintaining it. This will avoid code from being written like in ResourceLoader from working in one environment and breaking in another. Instead it will never work and thus force us to consistently deal with this after retrieval. We'd get patterns like proposed in https://gerrit.wikimedia.org/r/#/c/103407 in more places, but at least it would become part of expected behaviour and we'd have to do it consistently. * Figure out a way to support integers even for backends like Redis that don't support it fully. Note that though Redis doesn't support storing integers in a way that comes back out, it does have integer operations (e.g. it has native INCR, and it will work on values that look like integers, regardless of whether PHP provided these as integers or strings, they all become strings). -------------------------- **Version**: 1.23.0 **Severity**: normal ****See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=56069