Mysql: Fornece os tipos uint32 e uint64

Criado em 28 nov. 2017 · 7Comentários · Fonte: go-sql-driver/mysql

Descrição do problema

Ao usar o tipo INT do MySQL regular como chave primária, os usuários geralmente criam o tipo com INT UNSIGNED que é 32b sem sinal int. No entanto, não existe tal tipo no pacote db.sql básico.

Eu discuti isso no reddit e todos sugeriram escrever este tipo. No entanto, parece-me que isso deveria estar em uma biblioteca para ser reaproveitado. Eu acho que deveria estar nesta biblioteca, uma vez que é um tipo específico do MySQL (os tamanhos dos bytes são) e não acho que poderíamos empurrá-lo para o pacote db.sql.

Eu acredito que as estruturas devem representar corretamente os tipos de dados no MySQL para que não haja overflows, o que aconteceria ao usar NullInt64 para salvar dados em INT UNSIGNED . O mesmo se aplica ao usar BIGINT UNSIGNED - cujo valor máximo não caberá em NullInt64.

Código de exemplo

type MyTable struct {
    ID uint
}

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

Eu poderia criar esses tipos, só queria perguntar antes de escrevê-los se você concordaria com eles neste pacote.
Obrigada.

databassql issue enhancement question

Fonte

lunemec

👍1

Comentários muito úteis

@arnehormann, houve uma discussão sobre isso no banco de dados Go / pacote sql github, onde rsc disse que este suporte deve ser adicionado ao driver mysql golang especificamente (porque nem todos os bancos de dados suportam esses valores grandes).

Veja aqui: https://github.com/golang/go/issues/9373

lunemec em 1 dez. 2017

👍16

Todos 7 comentários

Estamos vinculados a https://golang.org/pkg/database/sql/driver/#Value - e o driver está se comunicando com o banco de dados / sql dentro dessas restrições. Exceto para NullTime que estava faltando no banco de dados / sql, não adicionaremos tipos adicionais.

arnehormann em 29 nov. 2017

Veja aqui: https://github.com/golang/go/issues/9373

lunemec em 1 dez. 2017

👍16

Sim, ele escreveu:
`` `Existem bancos de dados (sqlite, por exemplo) que não suportam valores tão grandes.
É por isso que o banco de dados / sql não permite isso por padrão.
Não podemos mudar essa decisão agora, porque isso quebrará todos os drivers existentes.

Se o MySQL suportar valores tão grandes, o driver MySQL pode tornar seu
implementação de driver.Stmt implementar driver.ColumnConverter e permitir
uint64s em um ValueConverter personalizado.

Ou seja, um driver MySQL que deseja permitir grandes uint64s pode fazer isso hoje.
Não há necessidade de mudança de código no banco de dados / sql.
`` `

Eu concordo, isso é necessário, ainda mais importante para o uint32 em vez do uint64, porque o uint64 tem menos probabilidade de estourar em breve.
Como fazemos isso acontecer? Estou disposto a ajudar a criar uma solicitação pull para isso.

mastertheknife em 22 set. 2020

Já suportamos uint64.

methane em 23 set. 2020

Já suportamos uint64.

Mas não NullUint64, que deve ser usado para o campo anulável BIGINT UNSIGNED.
É necessário usar NullInt64 em vez disso, o que pode disparar o estouro.

mastertheknife em 23 set. 2020

Você mencionou o comentário do rsc sobre o uint64, então respondi que ele já está implementado conforme sugerido pelo rsc.
Se você está propondo NullUint64 em vez de uint64, diga isso sem mencionar o comentário do rsc. É apenas confuso.

methane em 23 set. 2020

Já suportamos uint64.
Mas não NullUint64, que deve ser usado para o campo anulável BIGINT UNSIGNED.
É necessário usar NullInt64 em vez disso, o que pode disparar o estouro.

Eu criei um pacote que resolve esse tipo de problema

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