GitHub/gitea - gitea - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
KN4CK3R	a2651c14ce	Add cache for common package queries (#22491 ) This adds a cache for common package queries in `GetPackageDescriptor`. Code which needs to process a list of packages benefits from this change. This skips 350 queries in the package integration tests for example. --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>	8 months ago
Lunny Xiao	4a5af4edca	Cache GPG keys, emails and users when list commits (#34086 ) When list commits, some of the commits authors are the same at many situations. But current logic will always fetch the same GPG keys from database. This PR will cache the GPG keys, emails and users for the context so that reducing the database queries. --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>	8 months ago
TheFox0x7	0fde8ecd55	Enable testifylint rules (#34075 ) enable testifylint rules disabled in: https://github.com/go-gitea/gitea/pull/34054	9 months ago
TheFox0x7	cc1fdc84ca	Use test context in tests and new loop system in benchmarks (#33648 ) Replace all contexts in tests with go1.24 t.Context() --------- Co-authored-by: Giteabot <teabot@gitea.io> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>	10 months ago
Jason Song	a323a82ec4	Increase `cacheContextLifetime` to reduce false reports (#32011 ) Replace #32001. To prevent the context cache from being misused for long-term work (which would result in using invalid cache without awareness), the context cache is designed to exist for a maximum of 10 seconds. This leads to many false reports, especially in the case of slow SQL. This PR increases it to 5 minutes to reduce false reports. 5 minutes is not a very safe value, as a lot of changes may have occurred within that time frame. However, as far as I know, there has not been a case of misuse of context cache discovered so far, so I think 5 minutes should be OK. Please note that after this PR, if warning logs are found again, it should get attention, at that time it can be almost 100% certain that it is a misuse.	1 year ago
Jason Song	1960ad5c90	Improve cache context (#23330 ) Related to: #22294 #23186 #23054 Replace: #23218 Some discussion is in the comments of #23218. Highlights: - Add Expiration for cache context. If a cache context has been used for more than 10s, the cache data will be ignored, and warning logs will be printed. - Add `discard` field to `cacheContext`, a `cacheContext` with `discard` true will drop all cached data and won't store any new one. - Introduce `WithNoCacheContext`, if one wants to run long-life tasks, but the parent context is a cache context, `WithNoCacheContext(perentCtx)` will discard the cache data, so it will be safe to keep the context for a long time. - It will be fine to treat an original context as a cache context, like `GetContextData(context.Backgraud())`, no warning logs will be printed. Some cases about nesting: When: - A, B or C means a cache context. - ~A~, ~B~ or ~C~ means a discard cache context. - `ctx` means `context.Backgrand()` - A(ctx) means a cache context with `ctx` as the parent context. - B(A(ctx)) means a cache context with `A(ctx)` as the parent context. - `With` means `WithCacheContext` - `WithNo` means `WithNoCacheContext` So: - `With(ctx)` -> A(ctx) - `With(With(ctx))` -> A(ctx), not B(A(ctx)) - `With(With(With(ctx)))` -> A(ctx), not C(B(A(ctx))) - `WithNo(ctx)` -> ctx, not ~A~(ctx) - `WithNo(With(ctx))` -> ~A~(ctx) - `WithNo(WithNo(With(ctx)))` -> ~A~(ctx), not ~B~(~A~(ctx)) - `With(WithNo(With(ctx)))` -> B(~A~(ctx)) - `WithNo(With(WithNo(With(ctx))))` -> ~B~(~A~(ctx)) - `With(WithNo(With(WithNo(With(ctx)))))` -> C(~B~(~A~(ctx)))	3 years ago
Lunny Xiao	bd820aa9c5	Add context cache as a request level cache (#22294 ) To avoid duplicated load of the same data in an HTTP request, we can set a context cache to do that. i.e. Some pages may load a user from a database with the same id in different areas on the same page. But the code is hidden in two different deep logic. How should we share the user? As a result of this PR, now if both entry functions accept `context.Context` as the first parameter and we just need to refactor `GetUserByID` to reuse the user from the context cache. Then it will not be loaded twice on an HTTP request. But of course, sometimes we would like to reload an object from the database, that's why `RemoveContextData` is also exposed. The core context cache is here. It defines a new context ```go type cacheContext struct { ctx context.Context data map[any]map[any]any lock sync.RWMutex } var cacheContextKey = struct{}{} func WithCacheContext(ctx context.Context) context.Context { return context.WithValue(ctx, cacheContextKey, &cacheContext{ ctx: ctx, data: make(map[any]map[any]any), }) } ``` Then you can use the below 4 methods to read/write/del the data within the same context. ```go func GetContextData(ctx context.Context, tp, key any) any func SetContextData(ctx context.Context, tp, key, value any) func RemoveContextData(ctx context.Context, tp, key any) func GetWithContextCache[T any](ctx context.Context, cacheGroupKey string, cacheTargetID any, f func() (T, error)) (T, error) ``` Then let's take a look at how `system.GetString` implement it. ```go func GetSetting(ctx context.Context, key string) (string, error) { return cache.GetWithContextCache(ctx, contextCacheKey, key, func() (string, error) { return cache.GetString(genSettingCacheKey(key), func() (string, error) { res, err := GetSettingNoCache(ctx, key) if err != nil { return "", err } return res.SettingValue, nil }) }) } ``` First, it will check if context data include the setting object with the key. If not, it will query from the global cache which may be memory or a Redis cache. If not, it will get the object from the database. In the end, if the object gets from the global cache or database, it will be set into the context cache. An object stored in the context cache will only be destroyed after the context disappeared.	3 years ago