There is no result for "Mirrors" -> can someone confirm it's not working on postgress???

[somera]

• Gitea version (or commit ref): 1.12.5
• Operating system: Ubuntu 20.04.1
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
• Log gist:

Description

I have 6 projects with gitea in the project name. When I switch to "Mirrors" I see 0. But I should see 6 projects? All 6 are mirrors.

O I misunderstand the "Mirrors" tab.

Screenshots

[6543]

works on mysql ... can someone confirm it's not working on postgress?

[somera]

I'm using PostgreSQL 11.

[somera]

No one with PostgreSQL?! ;)

[somera]

Gitea 1.12.6 still same problem.

[somera]

Gitea 1.13.0 still same problem.

[6543]

sqlite3 works too

[lafriks]

I can confirm it is not working on postgres for me also on 1.13.0

[somera]

Same with 1.16.6.

[somera]

1.19.3 ... still not working.

[lunny]

I cannot reproduce this both in main and release/v1.19

OS: macOS
DB: postgres:13.4

Do you noticed some error logs when click mirrors tab? If not, could you paste your generated query logs here?

[somera]

I can't see any error. I'm running it on Ubuntu 20.04. with PostgreSQL and Memcached. Gitea project is an mirror.

But

Log when I click on mirror tab
2023/05/04 13:17:02 models/user/user.go:933:GetUserByID() [I] [6453942e] [SQL] SELECT "id", "lower_name", "name", "full_name", "email", "keep_email_private", "email_notifications_preference", "passwd", "passwd_hash_algo", "must_change_password", "login_type", "login_source", "login_name", "type", "location", "website", "rands", "salt", "language", "description", "created_unix", "updated_unix", "last_login_unix", "last_repo_visibility", "max_repo_creation", "is_active", "is_admin", "is_restricted", "allow_git_hook", "allow_import_local", "allow_create_organization", "prohibit_login", "avatar", "avatar_email", "use_custom_avatar", "num_followers", "num_following", "num_stars", "num_repos", "num_teams", "num_members", "visibility", "repo_admin_change_team_access", "diff_view_style", "theme", "keep_activity_private" FROM "user" WHERE "id"=$1 LIMIT 1 [1] - 1.036146ms 2023/05/04 13:17:02 .../issues/stopwatch.go:139:HasUserStopwatch() [I] [6453942e] [SQL] SELECT "id", "issue_id", "user_id", "created_unix" FROM "stopwatch" WHERE (user_id = $1) LIMIT 1 [1] - 518.482µs 2023/05/04 13:17:02 ...ls/repo/repo_list.go:531:SearchRepositoryByCondition() [I] [6453942e] [SQL] SELECT count(*) FROM "repository" WHERE owner_id=$1 AND (id IN (SELECT repo_topic.repo_id FROM repo_topic INNER JOIN topic ON topic.id = repo_topic.topic_id WHERE topic.name LIKE $2 GROUP BY repo_topic.repo_id) OR lower_name LIKE $3) AND is_mirror=$4 AND is_archived=$5 [1 %gitea% %gitea% true false] - 10.446745ms 2023/05/04 13:17:02 ...ls/repo/repo_list.go:541:SearchRepositoryByCondition() [I] [6453942e] [SQL] SELECT "id", "owner_id", "owner_name", "lower_name", "name", "description", "website", "original_service_type", "original_url", "default_branch", "num_watches", "num_stars", "num_forks", "num_issues", "num_closed_issues", "num_pulls", "num_closed_pulls", "num_milestones", "num_closed_milestones", "num_projects", "num_closed_projects", "num_action_runs", "num_closed_action_runs", "is_private", "is_empty", "is_archived", "is_mirror", "status", "is_fork", "fork_id", "is_template", "template_id", "size", "is_fsck_enabled", "close_issues_via_commit_in_any_branch", "topics", "trust_model", "avatar", "created_unix", "updated_unix" FROM "repository" WHERE owner_id=$1 AND (id IN (SELECT repo_topic.repo_id FROM repo_topic INNER JOIN topic ON topic.id = repo_topic.topic_id WHERE topic.name LIKE $2 GROUP BY repo_topic.repo_id) OR lower_name LIKE $3) AND is_mirror=$4 AND is_archived=$5 ORDER BY updated_unix DESC LIMIT 15 [1 %gitea% %gitea% true false] - 9.303862ms

[somera]

I know the "problem".

The query with the params is

SELECT "id", "owner_id", "owner_name", "lower_name", "name", "description", "website", "original_service_type", "original_url", "default_branch", "num_watches", "num_stars", "num_forks", "num_issues", "num_closed_issues", "num_pulls", "num_closed_pulls", "num_milestones", "num_closed_milestones", "num_projects", "num_closed_projects", "num_action_runs", "num_closed_action_runs", "is_private", "is_empty", "is_archived", "is_mirror", "status", "is_fork", "fork_id", "is_template", "template_id", "size", "is_fsck_enabled", "close_issues_via_commit_in_any_branch", "topics", "trust_model", "avatar", "created_unix", "updated_unix"
FROM repository r
WHERE owner_id=1 AND
(id IN (SELECT repo_topic.repo_id FROM repo_topic INNER JOIN topic ON topic.id = repo_topic.topic_id WHERE topic.name LIKE '%gitea%' GROUP BY repo_topic.repo_id) OR lower_name LIKE '%gitea%')
AND is_mirror=true AND is_archived=false ORDER BY updated_unix DESC LIMIT 15

where owner_id=1 is the logged user (admin) id.

But the projects has other owner_id's

And this is not the same like the logged_user_id.

owner_id = orga_id

This is, why it's not working.

[wxiaoguang]

That's a design problem (not related to database)

These tabs: All Sources Forks Mirrors , only All lists the repositories of your own and in your org. Other tabs only list your own repositories. So what you see is the expected result of such design.

The question is: why the design is so? I don't know. Feel free to propose fixes for this behavior.

[somera]

The question is: why the design is so? I don't know. Feel free to propose fixes for this behavior.

@lunny ?

[lunny]

That's a design problem (not related to database)
These tabs: All Sources Forks Mirrors , only All lists the repositories of your own and in your org. Other tabs only list your own repositories. So what you see is the expected result of such design.
The question is: why the design is so? I don't know. Feel free to propose fixes for this behavior.

Maybe it should be consider as a bug? The scope of mirrors/sources/forks should be the same as All. I haven't touched these code for a long time so I don't remember the exact design on that time. But from now, I can see it's reasonable to keep the scope consistent.