Skip to content

fix(database/gdb): Resolve the bug where AllAndCount and ScanAndCount use the same specified cache key when enabling caching features, resulting in both count and select using the same cache #4339

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

LanceAdd
Copy link
Contributor

func main() {
	adapter := gcache.NewAdapterRedis(g.Redis())
	g.DB().GetCache().SetAdapter(adapter)
	result, count, err := g.Model("TBL_USER").Cache(gdb.CacheOption{
		Duration: 100 * time.Minute,
		Name:     "VIP",
	}).AllAndCount(false)
	g.DumpJson(result)
	fmt.Println(count, err)
}

执行这段查询后g.DumpJson(result)的结果是[ { "COUNT(1)": 5 } ],但是正确结果应该是五条用户信息,查看源代码后发现先执行的count查询和后来select查询都是直接使用了VIP这个缓存key,在redis中实际缓存key是SelectCache:VIP,第二步查询select获得的是count查询的缓存,所以查询结果是错的。因此在AllAndCountScanAndCount中包含的count应该使用SelectCache:CountCache:VIP这个缓存作为区分。仅仅只在这两种查询时使用前缀SelectCache:CountCache:避免和其他单独查询使用的缓存产生冲突
SCR-20250711-onhp

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant