Mysql: Proporcionar tipos uint32 y uint64

Creado en 28 nov. 2017 · 7Comentarios · Fuente: go-sql-driver/mysql

Descripcion del problema

Cuando se usa el tipo INT de MySQL normal como clave principal, los usuarios generalmente crean el tipo con INT UNSIGNED que es 32b unsigned int. Sin embargo, no existe tal tipo en el paquete db.sql básico.

Discutí esto en reddit y todos sugirieron escribir este tipo. Sin embargo, me parece que esto debería estar en una biblioteca para ser reutilizado. Creo que debería estar en esta biblioteca, ya que es un tipo específico de MySQL (los tamaños de bytes son) y no creo que podamos enviarlo al paquete db.sql.

Creo que las estructuras deberían representar correctamente los tipos de datos en MySQL para que no haya desbordamientos, lo que sucedería cuando se usa NullInt64 para guardar datos en INT UNSIGNED . Lo mismo se aplica cuando se usa BIGINT UNSIGNED , cuyo valor máximo no cabe en NullInt64.

Código de ejemplo

type MyTable struct {
    ID uint
}

type MyOtherTable struct {
    ID uint
    MyTableID mysql.NullUint32 // Nullable relationship with MyTable
}

Podría crear estos tipos, solo quería preguntar antes de escribirlos si estaría de acuerdo con que estén en este paquete.
Gracias.

databassql issue enhancement question

Fuente

lunemec

👍1

Comentario más útil

@arnehormann hubo una discusión sobre esto en Go database / sql package github, donde rsc dijo que este soporte debería agregarse específicamente en el controlador golang mysql (porque no todas las bases de datos admiten estos valores grandes).

Ver aquí: https://github.com/golang/go/issues/9373

lunemec en 1 dic. 2017

👍16

Todos 7 comentarios

Estamos sujetos a https://golang.org/pkg/database/sql/driver/#Value , y el controlador se comunica con la base de datos / sql dentro de estas restricciones. Excepto por NullTime que faltaba en database / sql, no agregaremos tipos adicionales.

arnehormann en 29 nov. 2017

Ver aquí: https://github.com/golang/go/issues/9373

lunemec en 1 dic. 2017

👍16

Sí, escribió:
`` Hay bases de datos (sqlite por ejemplo) que no admiten valores tan grandes.
Es por eso que database / sql no permite esto de forma predeterminada.
No podemos cambiar esa decisión ahora, porque romperá todos los controladores existentes.

Si MySQL admite valores tan grandes, entonces el controlador MySQL puede hacer su
implementación de driver.Stmt implementar driver.ColumnConverter y permitir
uint64s en un ValueConverter personalizado.

Es decir, un controlador MySQL que quiera permitir uint64 grandes puede hacerlo hoy.
No se necesita ningún cambio de código en la base de datos / sql.
''

Estoy de acuerdo, esto es necesario, incluso más importante para uint32 que para uint64, porque es menos probable que uint64 se desborde pronto.
¿Cómo hacemos que suceda? Estoy dispuesto a ayudar a crear una solicitud de extracción para esto.

mastertheknife en 22 sept. 2020

Ya admitimos uint64.

methane en 23 sept. 2020

Ya admitimos uint64.

Pero no NullUint64, que debe usarse para el campo anulable BIGINT UNSIGNED.
Necesita usar NullInt64 en su lugar, que puede desencadenar un desbordamiento.

mastertheknife en 23 sept. 2020

Mencionaste el comentario de rsc sobre uint64, así que respondí que ya está implementado como sugirió rsc.
Si está proponiendo NullUint64 en lugar de uint64, dígalo sin mencionar el comentario de rsc. Es simplemente confuso.

methane en 23 sept. 2020

Ya admitimos uint64.
Pero no NullUint64, que debe usarse para el campo anulable BIGINT UNSIGNED.
Necesita usar NullInt64 en su lugar, que puede desencadenar un desbordamiento.

Creé un paquete que resuelve ese tipo de problema.

https://github.com/Thor-x86/nullable