Heatmap Rendering broken #3091

New Issue

GiteaMirror · 2025-11-02T05:00:30-06:00

GiteaMirror commented

2025-11-02 05:00:30 -06:00

Originally created by @openstack8 on GitHub (Mar 21, 2019).

Gitea version (or commit ref):
Git version:
Operating system:
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

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

Originally created by @openstack8 on GitHub (Mar 21, 2019).   - Gitea version (or commit ref): - Git version: - Operating system: - Database (use `[x]`): - [X] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [X] Not relevant - Log gist: ## 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](https://user-images.githubusercontent.com/27770487/54740723-2a49dd80-4bf7-11e9-8ab5-ee5a61d23f53.png)

GiteaMirror added the type/bug label 2025-11-02 05:00:30 -06:00

GiteaMirror closed this issue

2025-11-02 05:00:30 -06:00

GiteaMirror commented

2025-11-02 05:00:30 -06:00

@oscarlofwenhamn commented on GitHub (Mar 21, 2019):

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.

@oscarlofwenhamn commented on GitHub (Mar 21, 2019): 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.

GiteaMirror commented

2025-11-02 05:00:31 -06:00

@openstack8 commented on GitHub (Mar 21, 2019):

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.

@openstack8 commented on GitHub (Mar 21, 2019): 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.

GiteaMirror commented

2025-11-02 05:00:31 -06:00

@oscarlofwenhamn commented on GitHub (Mar 21, 2019):

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?

@oscarlofwenhamn commented on GitHub (Mar 21, 2019): It looks like this might come from a switch in the GetHeatmapDataByUser function (models\user_heatmap.go): ```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?

GiteaMirror commented

2025-11-02 05:00:31 -06:00

@openstack8 commented on GitHub (Mar 22, 2019):

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

@openstack8 commented on GitHub (Mar 22, 2019): 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

GiteaMirror commented

2025-11-02 05:00:31 -06:00

@zhanglt commented on GitHub (Apr 2, 2019):

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)

@zhanglt commented on GitHub (Apr 2, 2019): 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)

GiteaMirror commented

2025-11-02 05:00:31 -06:00

@502647092 commented on GitHub (Apr 9, 2019):

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"
}

@502647092 commented on GitHub (Apr 9, 2019): same problem gitea/gitea:1.8 ```json { "message": "Error 1305: FUNCTION gitea.strftime does not exist", "url": "https://godoc.org/github.com/go-gitea/go-sdk/gitea" } ```

GiteaMirror commented

2025-11-02 05:00:31 -06:00

@kolaente commented on GitHub (Apr 9, 2019):

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

@kolaente commented on GitHub (Apr 9, 2019): @zhanglt @502647092 Anything in `data/gitea/log/gitea.log`?

GiteaMirror commented

2025-11-02 05:00:32 -06:00

@mrsdizzie commented on GitHub (Apr 9, 2019):

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.

@mrsdizzie commented on GitHub (Apr 9, 2019): 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.

GiteaMirror commented

2025-11-02 05:00:32 -06:00

@502647092 commented on GitHub (Apr 10, 2019):

after restart docker container fix this problem

@502647092 commented on GitHub (Apr 10, 2019): after restart docker container fix this problem

GiteaMirror commented

2025-11-02 05:00:32 -06:00

@kolaente commented on GitHub (Apr 10, 2019):

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 commented on GitHub (Apr 10, 2019): > 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...

GiteaMirror commented

2025-11-02 05:00:32 -06:00

@mrsdizzie commented on GitHub (Apr 10, 2019):

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

@mrsdizzie commented on GitHub (Apr 10, 2019): @kolaente I suspect restarting Docker was just a way to guarantee Gitea was restarted here

GiteaMirror referenced this issue

2025-11-02 12:18:30 -06:00

[PR #3091] [MERGED] fix button heights on commits page #16761

Sign in to join this conversation.