go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.39k stars 5.43k forks source link

Heatmap Rendering broken #6405

Closed openstack8 closed 5 years ago

openstack8 commented 5 years ago

Description

run gitea v1.9.0-dev with postgresql 10.5,

issue: access /api/v1/users/username/heatmap message "pq: function from_unixtime(bigint) does not exist"

Screenshots

image

oscarlofwenhamn commented 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.

openstack8 commented 5 years ago

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.

oscarlofwenhamn commented 5 years ago

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?

openstack8 commented 5 years ago

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

zhanglt commented 5 years ago

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)

502647092 commented 5 years ago

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"
}
kolaente commented 5 years ago

@zhanglt @502647092 Anything in data/gitea/log/gitea.log?

mrsdizzie commented 5 years ago

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.

502647092 commented 5 years ago

after restart docker container fix this problem

kolaente commented 5 years ago

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...

mrsdizzie commented 5 years ago

@kolaente I suspect restarting Docker was just a way to guarantee Gitea was restarted here