fix(2meet-data-optimizer-hivepress-addon): 0.5.3 view-count flush keeps flat row and meta cache in sync
Tests / PHP Lint (pull_request) Successful in 6s
Tests / Unit Tests (pull_request) Successful in 53s
Tests / Integration Tests (pull_request) Successful in 1m13s

flush_views_to_postmeta() adds warm-zone views back with a direct UPDATE,
which the Hook Bus never sees: under dual_write/shadow_read the
hp_listing_core.hp_view_count column drifted after every hourly batch and
the (Redis) object cache kept the old count. After the UPDATE, drop the
post's meta cache and, while native is still the source of truth, rebuild
the entity's flat row with migrate_entity().
This commit is contained in:
2026-10-07 10:12:26 +08:00
parent 5953a5ed3b
commit 763f705ac1
3 changed files with 52 additions and 2 deletions
+14
View File
@@ -11,6 +11,20 @@ Versioning follows [Semantic Versioning](https://semver.org/).
---
## [0.5.3] — 2026-10-07 — 瀏覽數 flush 不再造成漂移
### Fixed
- **`TMDO_Listing_Stats::flush_views_to_postmeta()` 寫完後同步扁平表與快取**:每小時把 warm zone 的瀏覽數
用原子 `UPDATE … meta_value + N` 加回 `hp_view_count`,繞過了 meta API:Hook Bus 看不到這次寫入,
dual_write/shadow_read 下 `hp_listing_core.hp_view_count` 每批落後一次(夜間 drift-check 每晚 diff),
物件快取(Redis 下跨請求)也一直是舊值。現在 UPDATE 之後清掉該篇的 `post_meta` 快取,
並在原生仍是真相時(同時寫原生與扁平)用 `TMDO_Entity_Migration_Engine::migrate_entity()` 重建那一列。
`hp_view_count` 同時在 `hp_listing_core` 與 `hp_request_core`:只重建含這個 key、而且適用該篇 post type 的群組
(不帶 post type 的 `get_field()` 只回最後登記的那組)。aeav_only 不動(扁平才是真相)。
---
## [0.5.2] — 2026-10-05 — attribute bridge 的 meta key
### Fixed