Closed openstack8 closed 5 years ago
I had a similar issue when updating between versions, not all files had merged correctly. Is this the first version you are running or have you upgraded from an old version? If so, have you tried pulling a fresh instance to see locally if the problem persists?
Mine was solved by double checking the majority of the file tree, to make sure everything was up to date, including making sure my custom templates weren't slacking behind.
first run , not update。 Retrieve the latest gitea image Gitea version 6f2e1bd built with go1.12.1 : bindata, sqlite, sqlite_unlock_notify
The result is the same.
It looks like this might come from a switch in the GetHeatmapDataByUser function (models\user_heatmap.go):
case setting.UseSQLite3:
groupBy = "strftime('%s', strftime('%Y-%m-%d', created_unix, 'unixepoch'))"
case setting.UseMySQL:
groupBy = "UNIX_TIMESTAMP(DATE(FROM_UNIXTIME(created_unix)))"
case setting.UsePostgreSQL:
groupBy = "extract(epoch from date_trunc('day', to_timestamp(created_unix)))"
case setting.UseMSSQL:
groupBy = "datediff(SECOND, '19700101', dateadd(DAY, 0, datediff(day, 0, dateadd(s, created_unix, '19700101'))))"
groupByName = groupBy
Have you checked the app.ini file to see what database type is set, seeing as the FROM_UNIXTIME only should be running if you were using MySQL?
Yes, app.ini file set the database type. I use Postgresql 10.5. use docker pull gitea/gitea
bash-4.4# gitea -v Gitea version 6f2e1bd built with go1.12.1 : bindata, sqlite, sqlite_unlock_notify
[database] PATH = /data/gitea/gitea.db DB_TYPE = postgres HOST = 100.84.29.83:5432 NAME = gitea USER = gitea PASSWD = gitea SSL_MODE = disable
In the same environment, v1.7.4 does not have this problem
mysql:5.7 postgresql:96 have the same problem,. but in sqlit3 not any problem .
gitea logs: Completed GET /api/v1/users/root/heatmap 500 Internal Server Error in 7.83487ms browers logs /api/v1/users/root/heatmap:1 Failed to load resource: the server responded with a status of 500 (Internal Server Error)
same problem gitea/gitea:1.8
{
"message": "Error 1305: FUNCTION gitea.strftime does not exist",
"url": "https://godoc.org/github.com/go-gitea/go-sdk/gitea"
}
@zhanglt @502647092 Anything in data/gitea/log/gitea.log
?
All of these problems have similar symptom where gitea is choosing the wrong Database type based on what is in the config file.
That switch case is pretty simple and shouldn't fail, but can fail in this exact way if somebody changes the database type/information in the app.ini file and doesn't restart Gitea afterwards. I'm not familiar with the Docker setup at all and if that needs to be restarted too.
For these cases, have people restarted gitea/docker and if so does the problem go away? Or still the same error.
after restart docker container fix this problem
That switch case is pretty simple and shouldn't fail, but can fail in this exact way if somebody changes the database type/information in the app.ini file and doesn't restart Gitea afterwards. I'm not familiar with the Docker setup at all and if that needs to be restarted too.
@mrsdizzie AFAIK Gitea parses the config file only when it starts, if something is changed in the config file, Gitea does not notice until a new restart.
But wired the problem goes away if the container is restarted...
@kolaente I suspect restarting Docker was just a way to guarantee Gitea was restarted here
[x]
):Description
run gitea v1.9.0-dev with postgresql 10.5,
Screenshots