bleedingdeacons / concordance / 35408781192

94%

push

github

fix: flush the cache by generation, not by deleting option rows (#52)

ApiCache::flush() ran a DELETE against wp_options matching
_transient_concordance_%. That works only for as long as transients live
in the database. With a persistent object cache set_transient() writes to
the cache instead, no rows match, and the flush cleared nothing while
reporting success -- it returned 0, which reads exactly like an
already-empty cache. Memcached is being turned on, so this was about to
start lying.

Every key now carries a generation held in one option, and flushing
increments it. Existing entries become unreachable at once and expire on
their own TTL. That behaves identically with or without an object cache,
which the DELETE never did, and it drops a raw query that needed a
phpcs:ignore for two separate sniffs.

Enumerating the keys to delete them one by one was never an option: they
are md5 hashes of query arguments, which is why the DELETE existed.

flush() therefore returns bool rather than a count, because nothing is
enumerated any more. The admin notice becomes "Cache flushed." and the
CLI "Cache flushed.", losing a number that counted deleted database rows
rather than cached entries -- and that was always zero on any site with
an object cache. A stale redirect carrying a digit renders no notice.

Deliberately not built on Unity's Cache or CacheBumper: Concordance is
standalone, with its own container and no Unity dependency, and this
keeps it that way.

19 of 19 new or added lines in 3 files covered. (100.0%)

1218 of 1287 relevant lines covered (94.64%)

7.0 hits per line