github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-16 21:23:02 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

MYSQL: Database error on installation #518

New Issue
Closed
opened 2025-11-02 03:26:27 -06:00 by GiteaMirror · 16 comments
GiteaMirror commented 2025-11-02 03:26:27 -06:00
Owner
Copy Link

Originally created by @pree on GitHub (Mar 16, 2017).

Originally assigned to: @lunny on GitHub.

Description

Getting the following Database Error when installing on a empty Database.
Database setting is not correct: Error 1170: BLOB/TEXT column 'key_id' used in key specification without a key length

MySQL-Server Version: 10.0.30-MariaDB-0+deb8u1

Screenshots

image

Originally created by @pree on GitHub (Mar 16, 2017). Originally assigned to: @lunny on GitHub. - Gitea version (or commit ref): 447c9b428f4cf50174ef7f3fbea56b5405f6bbf8 - Git version: 2.1.4 - Operating system: Debian - Database (use `[x]`): - [ ] PostgreSQL - [X] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [X] Not relevant - Log gist: https://gist.github.com/Schizopriest/d6ccdad0170812dfb5bc510f8c283d76 ## Description Getting the following Database Error when installing on a empty Database. `Database setting is not correct: Error 1170: BLOB/TEXT column 'key_id' used in key specification without a key length` MySQL-Server Version: `10.0.30-MariaDB-0+deb8u1` ## Screenshots ![image](https://cloud.githubusercontent.com/assets/9799276/23990790/65827e74-0a37-11e7-9733-adf97f278b9f.png)
GiteaMirror added the type/bug label 2025-11-02 03:26:27 -06:00
GiteaMirror commented 2025-11-02 03:26:28 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Mar 16, 2017):

We haven't tested on Mariadb although it should be the same as MySQL.

@lunny commented on GitHub (Mar 16, 2017): We haven't tested on Mariadb although it should be the same as MySQL.
GiteaMirror commented 2025-11-02 03:26:28 -06:00
Author
Owner
Copy Link

@cez81 commented on GitHub (Mar 16, 2017):

Just tested this on a fresh install of prebuilt 1.1.0 with 10.0.29-MariaDB-0ubuntu0.16.04.1 on Ubuntu 16.04. InnoDB as engine.
It installs without any errors for me. Been using MariaDB on my production setup without any problems.

Edit:: But 1.1.0+38-gf1d2f16 fails...

@cez81 commented on GitHub (Mar 16, 2017): Just tested this on a fresh install of prebuilt 1.1.0 with 10.0.29-MariaDB-0ubuntu0.16.04.1 on Ubuntu 16.04. InnoDB as engine. It installs without any errors for me. Been using MariaDB on my production setup without any problems. Edit:: But 1.1.0+38-gf1d2f16 fails...
GiteaMirror commented 2025-11-02 03:26:28 -06:00
Author
Owner
Copy Link

@Diablofan commented on GitHub (Mar 16, 2017):

I can confirm this happening with MariaDB as well. Tried using the docker image 81f5b797cd07 (latest as of March 16 at 5:41 PM EST), and I was getting this error when trying a fresh install of gitea. Trying with the image tagged 1.1.0 works just fine.

@Diablofan commented on GitHub (Mar 16, 2017): I can confirm this happening with MariaDB as well. Tried using the docker image 81f5b797cd07 (latest as of March 16 at 5:41 PM EST), and I was getting this error when trying a fresh install of gitea. Trying with the image tagged 1.1.0 works just fine.
GiteaMirror commented 2025-11-02 03:26:29 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Mar 17, 2017):

Oh, maybe it's effected by GPG PR. Let me check.

@lunny commented on GitHub (Mar 17, 2017): Oh, maybe it's effected by GPG PR. Let me check.
GiteaMirror commented 2025-11-02 03:26:29 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Mar 17, 2017):

This is the bug here. A text column should not be a index. https://github.com/go-gitea/gitea/blob/master/models/gpg_key.go#L23 @sapk what's the max length of a key_id?

@lunny commented on GitHub (Mar 17, 2017): This is the bug here. A `text` column should not be a `index`. https://github.com/go-gitea/gitea/blob/master/models/gpg_key.go#L23 @sapk what's the max length of a `key_id`?
GiteaMirror commented 2025-11-02 03:26:29 -06:00
Author
Owner
Copy Link

@sapk commented on GitHub (Mar 17, 2017):

From https://tools.ietf.org/html/rfc4880#section-12.2 "The Key ID is the
low-order 64 bits of the fingerprint." So in hex 64/4 = 16 char

@sapk commented on GitHub (Mar 17, 2017): From https://tools.ietf.org/html/rfc4880#section-12.2 "The Key ID is the low-order 64 bits of the fingerprint." So in hex 64/4 = 16 char
GiteaMirror commented 2025-11-02 03:26:30 -06:00
Author
Owner
Copy Link

@sapk commented on GitHub (Mar 17, 2017):

and in fact it's not even usefull to be a index since. I don't use the keyid to find key.

@sapk commented on GitHub (Mar 17, 2017): and in fact it's not even usefull to be a index since. I don't use the keyid to find key.
GiteaMirror commented 2025-11-02 03:26:30 -06:00
Author
Owner
Copy Link

@gzsombor commented on GitHub (Mar 17, 2017):

Changing from "INDEX TEXT NOT NULL" to "TEXT NOT NULL" solves the problem - at least for me.

@gzsombor commented on GitHub (Mar 17, 2017): Changing from "INDEX TEXT NOT NULL" to "TEXT NOT NULL" solves the problem - at least for me.
GiteaMirror commented 2025-11-02 03:26:30 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Mar 17, 2017):

@sapk so maybe we change the tag from INDEX TEXT NOT NULL to CHAR(16) NOT NULL to resolve this?

@lunny commented on GitHub (Mar 17, 2017): @sapk so maybe we change the tag from `INDEX TEXT NOT NULL` to `CHAR(16) NOT NULL` to resolve this?
GiteaMirror commented 2025-11-02 03:26:30 -06:00
Author
Owner
Copy Link

@sapk commented on GitHub (Mar 17, 2017):

it should but I can't test right now.

@sapk commented on GitHub (Mar 17, 2017): it should but I can't test right now.
GiteaMirror commented 2025-11-02 03:26:31 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Mar 17, 2017):

I will send a PR to fix this.

@lunny commented on GitHub (Mar 17, 2017): I will send a PR to fix this.
GiteaMirror commented 2025-11-02 03:26:31 -06:00
Author
Owner
Copy Link

@sapk commented on GitHub (Mar 17, 2017):

In fact we could even use a uint64 ?

@sapk commented on GitHub (Mar 17, 2017): In fact we could even use a uint64 ?
GiteaMirror commented 2025-11-02 03:26:31 -06:00
Author
Owner
Copy Link

@sapk commented on GitHub (Mar 17, 2017):

I have found maybe a optimization for validating more "quickly" since keyid is in signature but not I will have to test it a lot. So repassing #1150 in WIP

@sapk commented on GitHub (Mar 17, 2017): I have found maybe a optimization for validating more "quickly" since keyid is in signature but not I will have to test it a lot. So repassing #1150 in WIP
GiteaMirror commented 2025-11-02 03:26:31 -06:00
Author
Owner
Copy Link

@sapk commented on GitHub (Mar 17, 2017):

I use string because I use it as a string but the value is a uint64 even for primaryId. @lunny you can PR the change proposed CHAR(16) NOT NULL I will test it more of we can optimize DB for validation in #1150

@sapk commented on GitHub (Mar 17, 2017): I use string because I use it as a string but the value is a uint64 even for primaryId. @lunny you can PR the change proposed CHAR(16) NOT NULL I will test it more of we can optimize DB for validation in #1150
GiteaMirror commented 2025-11-02 03:26:32 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Mar 17, 2017):

OK

@lunny commented on GitHub (Mar 17, 2017): OK
GiteaMirror commented 2025-11-02 03:26:32 -06:00
Author
Owner
Copy Link

@sapk commented on GitHub (Mar 17, 2017):

To be more simple it will stay in string format for DB since it will limit format at display but I will use https://github.com/golang/crypto/blob/master/openpgp/packet/public_key.go#L705 the same func to transform uint64 of the keyid store in sign to search only for the good key and not pass over each key of user.

@sapk commented on GitHub (Mar 17, 2017): To be more simple it will stay in string format for DB since it will limit format at display but I will use https://github.com/golang/crypto/blob/master/openpgp/packet/public_key.go#L705 the same func to transform uint64 of the keyid store in sign to search only for the good key and not pass over each key of user.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#518
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?