sql.NullInt64
существует, потому что SQL null
не может быть представлен как Go int
.Это третье состояние, которое не может быть представлено каким-либо значением int
.
Одним из решений этого было бы представление таких значений SQL как *int
, но это потребовало бы выделения для случаев, когда значение не являетсяnull
в базе данных, а выделения плохо влияют на производительность.
Разработчики пакета SQL придумали решение NullInt64
, которое кодирует третье состояние нуля как дополнительный логический Valid
.Это не очень хорошее решение, но это лучшее, что мы можем получить.
Я не уверен, возможно ли написать маршаллер JSON для NullInt64
, который бы работал так, как вы ожидаете.
Все еще естьпроблема "третьего состояния" при сортировке в JSON.С ,omitempty
a 0
int также будет опущено, так как вы можете отличить 0 от «не существует» / null?
В любом случае они не написали собственный маршаллер для NullInt64
, поэтому он просто кодируетв качестве структуры.
Вы можете создать тип псевдонима для NullInt64
, написать маршаллер JSON для кодирования того, как вы хотите JSON (вам нужен псевдоним, потому что вы не можете добавлять методы в типыиз других пакетов).Вам также нужно будет разыграть между вашими NullInt64
и sql.NullInt64
.