Skip to content
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

store the foreign ID of issues during migration #18446

Merged
merged 12 commits into from
Mar 17, 2022

Conversation

realaravinth
Copy link
Contributor

@realaravinth realaravinth commented Jan 29, 2022

On behalf of Loïc Dachary:

Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.

At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.

The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:

  1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
  2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
  3. Optimize the Gitea uploader to speed up the updates, when possible.

The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.

The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.

The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.

The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.

The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.

The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.

The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.

The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.


source

@realaravinth
Copy link
Contributor Author

Overall this change removes more lines than it adds, which is a good sign.


source

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Jan 29, 2022
@realaravinth realaravinth marked this pull request as draft January 29, 2022 07:56
@codecov-commenter

This comment was marked as outdated.

models/migrations/migrations.go Outdated Show resolved Hide resolved
models/migrations/v1000.go Outdated Show resolved Hide resolved
@realaravinth realaravinth marked this pull request as ready for review January 31, 2022 18:04
@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Jan 31, 2022
@realaravinth realaravinth force-pushed the forgefriends-mr-36 branch 2 times, most recently from af89646 to 38ad1ca Compare February 1, 2022 12:46
@realaravinth
Copy link
Contributor Author

Apologies for the force-push mess. We ran into some issues while preparing the patch for upstream from forgefreinds.

Diff since @Gusted review only contains the changes suggested by them.

Copy link
Contributor

@Gusted Gusted left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still LGTM after force-push.

@singuliere singuliere requested a review from a team February 2, 2022 14:22
@singuliere singuliere added this to the 1.17.0 milestone Feb 2, 2022
@singuliere singuliere added type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/refactoring Existing code has been cleaned up. There should be no new functionality. topic/federation labels Feb 2, 2022
@6543
Copy link
Member

6543 commented Feb 2, 2022

what's the source of a foreignID ?

@realaravinth
Copy link
Contributor Author

@6543 the foreignID comes from the downloader and depends on the originating forge (gitea, gitlab, etc.). It represents the unique identifier of the Issue, Release etc. on the originating forge. Does that answer your question?


source

@6543
Copy link
Member

6543 commented Feb 3, 2022

yes, now I suggest to use string and not int - as identify could be a uuid

@realaravinth
Copy link
Contributor Author

@6543 It makes sense to store the foreign ID as a string in the database. A new commit was pushed to changed that.


source

@6543
Copy link
Member

6543 commented Feb 5, 2022

Please resolve conflict

@realaravinth
Copy link
Contributor Author

@6543 here you go, thanks for the reminder!


source

@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Feb 6, 2022
Copy link
Contributor

@Gusted Gusted left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a little oversight, otherwise L G T M

models/migrations/v210.go Outdated Show resolved Hide resolved
@realaravinth
Copy link
Contributor Author

A conflict appeared because a new migration was added to the main branch, it was resolved as follows:

	// v209 -> v210
	NewMigration("Increase WebAuthentication CredentialID size to 410 - NO-OPED", increaseCredentialIDTo410),
	// v210 -> v211
	NewMigration("v208 was completely broken - remigrate", remigrateU2FCredentials),
	// v211 -> v212
	NewMigration("Create ForeignReference table", createForeignReferenceTable),

And the v210.go file was renamed v211.go. The series of commit were force pushed to resolve the conflict and are otherwise not modified.


source

@singuliere
Copy link
Contributor

singuliere commented Feb 19, 2022

@wxiaoguang have all your review comments been addressed? Is there anything missing?

@singuliere
Copy link
Contributor

@go-gitea/mergers it looks like this PR can be merged. Or am I missing something?

@singuliere
Copy link
Contributor

make L G T M work

@singuliere
Copy link
Contributor

The CI failure does not seem to be related. @realaravinth you could merge the main branch and push to trigger it again so that it succeeds.

2022/03/04 16:34:35 ...disk_channel_test.go:260:func4() [I] Finally terminating

panic: runtime error: invalid memory address or nil pointer dereference

[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xa79901]


goroutine 133 [running]:

github.com/syndtr/goleveldb/leveldb.(*DB).isClosed(...)

	/go/pkg/mod/github.com/syndtr/goleveldb@v1.0.0/leveldb/db_state.go:230

github.com/syndtr/goleveldb/leveldb.(*DB).ok(...)

	/go/pkg/mod/github.com/syndtr/goleveldb@v1.0.0/leveldb/db_state.go:235

github.com/syndtr/goleveldb/leveldb.(*DB).Get(0x0, {0xc000237a68, 0x8, 0x8}, 0x0)

	/go/pkg/mod/github.com/syndtr/goleveldb@v1.0.0/leveldb/db.go:838 +0x81

gitea.com/lunny/levelqueue.(*Queue).RPop(0xc00028c680)

	/go/pkg/mod/gitea.com/lunny/levelqueue@v0.4.1/queue.go:198 +0x33c

code.gitea.io/gitea/modules/queue.(*LevelQueueByteFIFO).Pop(0xc000204420, {0x86c1ea, 0x460795})

	/drone/src/modules/queue/queue_disk.go:104 +0x52

code.gitea.io/gitea/modules/queue.(*ByteFIFOQueue).doPop(0xc000152140)

	/drone/src/modules/queue/queue_bytefifo.go:298 +0x136

code.gitea.io/gitea/modules/queue.(*ByteFIFOQueue).readToChan(0xc000152140)

	/drone/src/modules/queue/queue_bytefifo.go:233 +0x7c5

code.gitea.io/gitea/modules/queue.(*ByteFIFOQueue).Run(0xc000152140, 0xe13780, 0xe13788)

	/drone/src/modules/queue/queue_bytefifo.go:163 +0x3b3

created by code.gitea.io/gitea/modules/queue.(*PersistableChannelQueue).Run

	/drone/src/modules/queue/queue_disk_channel.go:176 +0x636

FAIL	code.gitea.io/gitea/modules/queue	1.168s

@realaravinth
Copy link
Contributor Author

Conflicts showed up on multiple commits in this pull request because another pull request was merged today. It does not change anything to the semantic and all conflict resolutions were related to the context of the diff hunks: a new field was added to the comment migration.

The series of commit were force pushed to resolve the conflicts and are otherwise not modified.


source

@singuliere
Copy link
Contributor

@go-gitea/mergers it looks like this PR can be merged.

@6543
Copy link
Member

6543 commented Mar 17, 2022

🚀

@6543 6543 merged commit fa73cbf into go-gitea:main Mar 17, 2022
zjjhot added a commit to zjjhot/gitea that referenced this pull request Mar 19, 2022
* giteaoffical/main:
  remove not needed (go-gitea#19128)
  Add warning to set SENDMAIL_ARGS to --  (go-gitea#19102)
  Do not send activation email if manual confirm is set (go-gitea#19119)
  Update tool dependencies (go-gitea#19120)
  Delete related notifications on issue deletion too (go-gitea#18953)
  nit fix (go-gitea#19116)
  Store the foreign ID of issues during migration  (go-gitea#18446)
  Remove italics for `due_date_not_set` (go-gitea#19113)
Chianina pushed a commit to Chianina/gitea that referenced this pull request Mar 28, 2022
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.

At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.

The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:

1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.

The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.

The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.

The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.

The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.

The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.

The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.

The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.

The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.

---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)

Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. topic/federation type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/refactoring Existing code has been cleaned up. There should be no new functionality.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants