Primary keys are required in MySQL DB cluster

[aqos156]

Description

We use a hosted MySQL DB cluster service on digital ocean which requires that all tables have primary keys. Since version 1.17 there are tables without primary keys. This has happened once already in #16802.

Are you able to fix this regression so we are able to update to the newest version? Thank you for your time.

Gitea Version

1.16.9 (trying to update to 1.17)

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/aqos156/b9b9b9f097ab926bec9be84fb34a1910

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Docker on swarm

Database

MySQL

[aqos156]

This problem is still persisting and relevant for us. We are unable to upgrade to the newest version.

[lunny]

ForeignReference table needs a primary key

[wxiaoguang]

Is the table really working for some purpose now? Or how is it planned to be used in the future?

If no use at the moment and nobody know how to use it properly in the future, then it could be dropped.

And add it back when it's really necessary and needed.

[lunny]

Is the table really working for some purpose now? Or how is it planned to be used in the future?

If no use at the moment and nobody know how to use it properly in the future, then it could be dropped.

And add it back when it's really necessary and needed.

Since it's on v1.17, we cannot add migrations, both adding primary key or removing the tables cannot be done automatically.

[wolfogre]

Is the table really working for some purpose now? Or how is it planned to be used in the future?
If no use at the moment and nobody know how to use it properly in the future, then it could be dropped.
And add it back when it's really necessary and needed.

Since it's on v1.17, we cannot add migrations, both adding primary key or removing the tables cannot be done automatically.

Maybe we can add a migration to add the primary key on v1.19, and move this issue to 1.19 milestone, I think it's better than endless waiting.

Then I will add a unit test to make sure a table without a primary key does not appear again, what the #21721 is trying to do.

And after that, we can discuss whether the table is necessary or not, and how to avoid adding unnecessary tables.

What do you think?

[wxiaoguang]

I would say that the table is only used by dead code. Instead of adding a migration for primary key, adding a migration to drop it also seems to be an option (if no maintainer really knows how it works)

[lunny]

I would say that the table is only used by dead code. Instead of adding a migration for primary key, adding a migration to drop it also seems to be an option (if no maintainer really knows how it works)

It's expected to be used in future federation PRs.

[wxiaoguang]

Yup, I know it was expected to be used in future federation PRs. But the question is how it works?

For my understanding, the ForeignIndex is used to store the federated Gitea's issue index. Does it really work for federated instances?

For example, suppose you have a repo-a with issues in Gitea Instance A, then you federate the repo-a to repo-b on Gitea Instance B, then you federate repo-b to repo-c on Gitea Instance C. If Instance B closes and quits the federation, how could you make the make repo-c sync(re-federate) with repo-a?

• The issues in repo-a could be : (index=1), (index=2)
• The issues in repo-b could be : (index=1, foreign_index=1(a)), (index=2), (index=3, foreign_index=2(a))
• The issues in repo-c could be : (index=1, foreign_index=1(b)), (index=2, foreign_index=2(b)), (index=3, foreign_index=3(b))

How could the instances re-federate if repo-b disappears?

[lunny]

I think this cannot be fixed automatically in v1.17/v1.18, users could add a id column with autoincrement and primary key manually.