- If the database returns a error in integration tests, it should be
marked as a failure of the test.
- Ref: https://codeberg.org/forgejo/forgejo/issues/2962 (this should
help with logging the SQL that is resulting in the error).
- I found this while doing some unrelated testing in Forgejo. It wasn't
my intention to log failed SQL queries if they were cancelled (which can
happen quite frequently for larger instances) as in those cases it's not
interesting to know which SQL query was run. My intentation was only to
log an SQL query if there was an error reported by the database.
- Ref #2140
- When the database returns an error about the SQL query, the error is
logged but not the SQL query and arguments, which is just as valuable as
the vague deeply hidden documented error that the database returns.
It's possible to log the SQL query by logging **all** SQL queries. For
bigger instances such as Codeberg, this is not a viable option.
- Adds a new hook, enabled by default, to log SQL queries with their
arguments and the error returned by the database when the database
returns an error.
- This likely needs some fine tuning in the future to decide when to
enable this, as the error is already logged and if people have the
`[database].LOG_SQL` option enabled, the SQL would be logged twice. But
given that it's an rare occurence for SQL queries to error, it's fine to
leave that as-is.
- Ref: https://codeberg.org/forgejo/forgejo/issues/1998
(cherry picked from commit 866229bc323619bc8686bad99951f95d5d46fe19)
(cherry picked from commit 96dd3e87cf5f75ac33bfad647e44852667c307d0)
(cherry picked from commit e165510317b3fe3be4fe49ad3ff0a055e7a92124)
(cherry picked from commit 1638e2b3f56a508dbf218207bf0c3c4d16493255)
- Databases are one of the most important parts of Forgejo, every
interaction with Forgejo uses the database in one way or another.
Therefore, it is important to maintain the database and recognize when
Forgejo is not doing well with the database. Forgejo already has the
option to log *every* SQL query along with its execution time, but
monitoring becomes impractical for larger instances and takes up
unnecessary storage in the logs.
- Add a QoL enhancement that allows instance administrators to specify a
threshold value beyond which query execution time is logged as a warning
in the xorm logger. The default value is a conservative five seconds to
avoid this becoming a source of spam in the logs.
- The use case for this patch is that with an instance the size of Codeberg, monitoring SQL logs is not very fruitful and most of them are uninteresting. Recently, in the context of persistent deadlock issues (https://codeberg.org/forgejo/forgejo/issues/220), I have noticed that certain queries hold locks on tables like comment and issue for several seconds. This patch helps to identify which queries these are and when they happen.
- Added unit test.
(cherry picked from commit 24bbe7886fb4cb9a38c8dab8c44f4c9cbfa25481)
(cherry picked from commit 6e29145b3c1455498531593d38e6a914941a12cb)
(cherry picked from commit 63731e30712872bd2395eb3cf36d9996e5793645)
(cherry picked from commit 3ce1a097369c132654de70df707b867e47bd1c40)
(cherry picked from commit a64426907de788cc0937a7a2b16af4d2f26f7fe6)
(cherry picked from commit 4b1921569156445c58d9889602733da5934c7b95)
(cherry picked from commit e6356744359fa947c049827d60c2ea0e277e03dc)
(cherry picked from commit 9cf501f1af4cd870221cef6af489618785b71186)
(cherry picked from commit 0d6b934eba1c0e9b27b364791113aae816b6b366)
(cherry picked from commit 4b6c2738795002887844a106f2fed2ef1673eed1)
(cherry picked from commit 89b1315338b0c7a726a36a84e9844013a13560b8)
(cherry picked from commit edd8e66ce991c395bb0af7720631c3cd26caaa51)
[GITEA] Add slow SQL query warning (squash) document the setting
(cherry picked from commit ce38599c5141c7fc6bc054819f5ff1c1b45bda1f)
(cherry picked from commit 794aa67c68c8e24ac7301eb7ef767c6e2499a78d)
(cherry picked from commit a4c2c6b004c21488e90f637ca7920f49108ed75d)
(cherry picked from commit 97912752bc802db79bb26a6591aec885aea30ee4)
(cherry picked from commit 00b5327c9750215a290238516e7b6fb1e6601e14)
(cherry picked from commit 1069c860e78c11225b4d74ff3044df7786562821)
(cherry picked from commit 84241f42c83852918b57c8bd25364697037fe42f)
(cherry picked from commit e4bda0e8457d00c01b83f153ed5a4a8ea4cf85c8)
(cherry picked from commit 7357fb91bff87045b133c3a7ac9fc70eea781bc4)
(cherry picked from commit a8dd7f6da278ae112200b5efa5bf27e3961f5996)
(cherry picked from commit e636e9f4beca7273dd8622baedb2f0c01db30449)
(cherry picked from commit bf04ae86037f5cb5a81d02750aead2742b040367)
(cherry picked from commit 93b19e3568169bd1cf9b8b78c1751c3d2d65a1b6)
(cherry picked from commit 83f91363ad071675c73a1f636271cc043bf69707)
(cherry picked from commit e34a05bc7319072b70d387975342d617b8136655)
(cherry picked from commit 68569aeee9805aaa8e98c6e7fe8058095e290061)
(cherry picked from commit b7fe7cf401f4bddd6455efc651f7ac054f3fe1cf)
(cherry picked from commit cf339eed4f4851b18448dbdd83df32d00bc6f45b)
(cherry picked from commit 4f3a16168bbeced519a60c32e10e2895d9367238)
(cherry picked from commit 6f5bbc53fcebd614f5ee8627c7d6e3c637ffa694)
(cherry picked from commit aca42b422e76668387769c15868ef77b073bb7db)
(cherry picked from commit 5a7f7580e525694d1f27e12329c8532bd29273f8)
(cherry picked from commit 06c383c807ad49e1e35b429a10c6a11c65aeebe5)
(cherry picked from commit fe831dcb53b81b6cc632be751bfcbfb9bc00efd3)
(cherry picked from commit cd12cd0dbce47c6117ea579ae5019c182155b3a9)
(cherry picked from commit cc79163703ce31706c86b88c38fb8a20ed745e20)
(cherry picked from commit 0102a5715ea6a03b560cc2f0b6cbe2b2576c255e)
(cherry picked from commit 403f7520b3056eace36eae505afbab6a05f597b7)
(cherry picked from commit a3b61510a246f61c174ddc3c288e556522a6aab9)
(cherry picked from commit f83f0f9feb76a8b62ca4d74dc2785c713fbec282)
(cherry picked from commit fd1c3a6d09a057070844cd955d0920518e60f408)
(cherry picked from commit f7cdc3d6f1ad1ff01bb1814207fcb41210db80e8)
(cherry picked from commit 060121b644e0515a6b673cdd514d52e6fa1e6ec3)
(cherry picked from commit 62c847ff0235196e73e860d0d1658f0734985270)
(cherry picked from commit 4d051b51c2813828b978ef84b6b72c0ba051741b)
(cherry picked from commit 86e6981a936b1937065605892083b2488424bf5e)
(cherry picked from commit c1fc9e441b1467033911f3848f82a89aaacf98a9)
(cherry picked from commit 8bb2f0871a507d881acf74acf8fb90fd5ebff567)
(cherry picked from commit 0cd9fe52511ee06f1b8849325d196f60d8ccd151)
(cherry picked from commit b0b44778b4d3e51852d0669dfe6d9a6c334b90e4)
(cherry picked from commit 7c2f4f749f1c8986875eebf95254a3db151e5248)
Mainly for MySQL/MSSQL.
It is important for Gitea to use case-sensitive database charset
collation. If the database is using a case-insensitive collation, Gitea
will show startup error/warning messages, and show the errors/warnings
on the admin panel's Self-Check page.
Make `gitea doctor convert` work for MySQL to convert the collations of
database & tables & columns.
* Fix #28131
## ⚠️ BREAKING ⚠️
It is not quite breaking, but it's highly recommended to convert the
database&table&column to a consistent and case-sensitive collation.
The xorm `Sync2` has already been deprecated in favor of `Sync`,
so let's do the same inside the Gitea codebase.
Command used to replace everything:
```sh
for i in $(ag Sync2 --files-with-matches); do vim $i -c ':%sno/Sync2/Sync/g' -c ':wq'; done
```
The recent change on xorm for `Sync` is it will not warn when database
have columns which is not listed on struct. So we just need this warn
logs when `Sync` the whole database but not in the migrations Sync.
This PR will remove almost unnecessary warning logs on migrations.
Now below logs in CI will disappear.
```log
2023/06/23 17:51:32 models/db/engine.go:191:InitEngineWithMigration() [W] Table gtestschema.project has column creator_id but struct has not related field
2023/06/23 17:51:32 models/db/engine.go:191:InitEngineWithMigration() [W] Table gtestschema.project has column is_closed but struct has not related field
2023/06/23 17:51:32 models/db/engine.go:191:InitEngineWithMigration() [W] Table gtestschema.project has column board_type but struct has not related field
2023/06/23 17:51:32 models/db/engine.go:191:InitEngineWithMigration() [W] Table gtestschema.project has column type but struct has not related field
2023/06/23 17:51:32 models/db/engine.go:191:InitEngineWithMigration() [W] Table gtestschema.project has column closed_date_unix but struct has not related field
2023/06/23 17:51:32 models/db/engine.go:191:InitEngineWithMigration() [W] Table gtestschema.project has column created_unix but struct has not related field
2023/06/23 17:51:32 models/db/engine.go:191:InitEngineWithMigration() [W] Table gtestschema.project has column updated_unix but struct has not related field
2023/06/23 17:51:32 models/db/engine.go:191:InitEngineWithMigration() [W] Table gtestschema.project has column card_type but struct has not related field
```
Replace #23350.
Refactor `setting.Database.UseMySQL` to
`setting.Database.Type.IsMySQL()`.
To avoid mismatching between `Type` and `UseXXX`.
This refactor can fix the bug mentioned in #23350, so it should be
backported.
Change all license headers to comply with REUSE specification.
Fix #16132
Co-authored-by: flynnnnnnnnnn <flynnnnnnnnnn@github>
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
A lot of our code is repeatedly testing if individual errors are
specific types of Not Exist errors. This is repetitative and unnecesary.
`Unwrap() error` provides a common way of labelling an error as a
NotExist error and we can/should use this.
This PR has chosen to use the common `io/fs` errors e.g.
`fs.ErrNotExist` for our errors. This is in some ways not completely
correct as these are not filesystem errors but it seems like a
reasonable thing to do and would allow us to simplify a lot of our code
to `errors.Is(err, fs.ErrNotExist)` instead of
`package.IsErr...NotExist(err)`
I am open to suggestions to use a different base error - perhaps
`models/db.ErrNotExist` if that would be felt to be better.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: delvh <dev.lh@web.de>
This PR adds a new manager command to switch on SQL logging and to turn it off.
```
gitea manager logging log-sql
gitea manager logging log-sql --off
```
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Move some repository related code into sub package
* Move more repository functions out of models
* Fix lint
* Some performance optimization for webhooks and others
* some refactors
* Fix lint
* Fix
* Update modules/repository/delete.go
Co-authored-by: delvh <dev.lh@web.de>
* Fix test
* Merge
* Fix test
* Fix test
* Fix test
* Fix test
Co-authored-by: delvh <dev.lh@web.de>
Upgrade builder to v0.3.11
Upgrade xorm to v1.3.1 and fixed some hidden bugs.
Replace #19821
Replace #19834
Included #19850
Co-authored-by: zeripath <art27@cantab.net>
This PR continues the work in #17125 by progressively ensuring that git
commands run within the request context.
This now means that the if there is a git repo already open in the context it will be used instead of reopening it.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Improve install code to avoid low-level mistakes.
If a user tries to do a re-install in a Gitea database, they gets a warning and double check.
When Gitea runs, it never create empty app.ini automatically.
Also some small (related) refactoring:
* Refactor db.InitEngine related logic make it more clean (especially for the install code)
* Move some i18n strings out from setting.go to make the setting.go can be easily maintained.
* Show errors in CLI code if an incorrect app.ini is used.
* APP_DATA_PATH is created when installing, and checked when starting (no empty directory is created any more).
* Run Migrate in Install rather than just SyncTables
The underlying problem in #17328 appears to be that users are re-running the install
page during upgrades. The function that tests and creates the db did not intend for
this and thus instead the migration scripts being run - a simple sync tables occurs.
This then causes a weird partially migrated DB which causes, in this release cycle,
the duplicate column in task table error. It is likely the cause of some weird
partial migration errors in other cycles too.
This PR simply ensures that the migration scripts are also run at this point too.
Fix #17328
Signed-off-by: Andrew Thornton <art27@cantab.net>
* DBContext is just a Context
This PR removes some of the specialness from the DBContext and makes it context
This allows us to simplify the GetEngine code to wrap around any context in future
and means that we can change our loadRepo(e Engine) functions to simply take contexts.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* fix unit tests
Signed-off-by: Andrew Thornton <art27@cantab.net>
* another place that needs to set the initial context
Signed-off-by: Andrew Thornton <art27@cantab.net>
* avoid race
Signed-off-by: Andrew Thornton <art27@cantab.net>
* change attachment error
Signed-off-by: Andrew Thornton <art27@cantab.net>
