-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Fix comment broken issue ref dependence #12651
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
Fix comment broken issue ref dependence #12651
Conversation
Codecov Report
@@ Coverage Diff @@
## master #12651 +/- ##
==========================================
+ Coverage 43.29% 43.30% +0.01%
==========================================
Files 646 646
Lines 71592 71567 -25
==========================================
- Hits 30993 30991 -2
+ Misses 35583 35557 -26
- Partials 5016 5019 +3
Continue to review full report at Codecov.
|
We should probably need migration that deletes all bad data |
might be but we usually did also migration in such cases |
@lafriks Done |
models/migrations/v148.go
Outdated
) | ||
|
||
func purgeInvalidDependenciesComments(x *xorm.Engine) error { | ||
_, err := x.Exec("DELETE FROM comment WHERE dependent_issue_id NOT IN (SELECT id FROM issue)") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a fan of this query for a few reasons
1, raw sql, when we could probably leverage xorm
2, IIRC sqlite may fail if select id from issue
too large due to "too many arguments"
3, default value of dependant_issue_id is 0, and this could end up deleting many comments as issue_id 0 doesn't exist
Perhaps this could be broken up into batches of queries of issues where dependant_issue_id != 0, this would increase the number of queries run, but it likely would lead to a safer migration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we may want to have a look at this too:
https://github.com/go-gitea/gitea/blob/master/models/migrations/v129.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the SQLite too many arguments issue is not the case here. That occurs if you do the selects in two stages and try to use "... IN (?)", []string{....})
Probably could use xorm here though although it would require two fake struct definitions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch on the 0 dependent_issue_id though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
think 1. & 2. can be considered as "resolved"
to 3. I'm happy if somebody can translate this query into xorm (/-builder), I had a try and it didnt worked out jet
@lunny done |
Please send back port to v1.12 |
( -> #12692 ) |
To reproduce the bug:
-> visit issue "OMG" -> 500
source: https://codeberg.org/Codeberg/Community/issues/242
note: need backport