Count only visible repos on profile

[JakobDev]

Fixes #25914

This should probably be backported

[silverwind]

Instead of adding another template property, couldn't we just show the length of the to-be-rendered repos? As I understand, this goes to database twice, which is wasteful.

[JakobDev]

Instead of adding another template property, couldn't we just show the length of the to-be-rendered repos?

This will not work. The repo count is always shown, no matter in which tab you are. But the list of repos is only loaded, when you are in the repos tab.

[silverwind]

Right, so only on the repo tab we could skip the count, hmm.

[JakobDev]

We could run this code only, when the Repository tab is not selected, but I'm not sure, if it's worth the effort.

[silverwind]

How long does the extra code it take with a moderate amount of repos? That should give us an estimation whether it is worth it.

[JakobDev]

I found out that the Bar rendered by a few more routes, so I decided to move the Code into a new function.

How long does the extra code it take with a moderate amount of repos?

What exactly did you mean with "moderate amount of repos"? 50? 100? 500? Counting in SQL is relay fast, so I don't think it matters that much, even with more Repos.

I also realized, that the same Problem apers in the Stars Tab. If you star an private Repo, you have for Visitors a higher Star Number than actually shown in the List.

[JakobDev]

I know realized this is harder than I though: If you give someone access to a private Repo, the private Repo will be shown when the other Person visits your profile, so the Count would be wrong. I have to find an alternative.

[silverwind]

What exactly did you mean with "moderate amount of repos"? 50? 100? 500? Counting in SQL is relay fast, so I don't think it matters that much, even with more Repos.

Yeah, likely not an issue. I recall at least in MySQL with InnoDB COUNT() is O(n) but given that repo numbers are at most in the thousands, it won't be an issue.

[JakobDev]

As I mentation, we have the Problem, that when a logged in User visits the Profile of another Use,w e need to check for each private Repo if the User has access, so a simple count is not enough.

[silverwind]

Indeed, this will need a complex query.

[JakobDev]

Can we run this on every profile visit or does this take to long just for displaying a number?

[silverwind]

Depends on runtime. If it's sub-100ms for 1k repos, I'd say go for it. If slower, some cache may be beneficial, but it'll be hard to invalidate correctly.

[JakobDev]

I changed the code now to use repo_model.SearchRepository

[silverwind]

Seems good to merge. Not sure we should backport it though.

[JakobDev]

This is a fix for a Bug hat was reported for 1.20 and doesn't introduce new Features, so I would say that it should be backported

The block problem has been resolved.

[GiteaBot]

I was unable to create a backport for 1.20. @JakobDev, please send one manually. 🍵

go run ./contrib/backport 25928
...  // fix git conflicts if any
go run ./contrib/backport --continue

[JakobDev]

$ go run ./contrib/backport 25928
Unable to read `docs/config.yaml`: open docs/config.yaml: no such file or directory
* Backporting 25928 to origin/release/v1.18 as backport-25928-v1.18
* `git fetch origin main`

* `git fetch origin release/v1.18`

Unable to backport: unable to fetch release/v1.18 from origin: exit status 128
$