go-zero
go-zero copied to clipboard
zeromicro
Why are the integers generated in goctl model mysql all int64?
Is it designed this way? Is there a plan to generate a corresponding golang integer type based on the integer type in mysql?
There are some considerations here. It has been designed to map golang types for integer types of different lengths for a long time. However, in many cases, database developers do not add unsigned constraints to unsigned types. Therefore, here is a summary and use Uniform and relatively long types can meet most scenarios. At present, it seems to be suitable for most users. Therefore, there is no entanglement here on whether the design change is a best practice or an unthinking design. It is just designed according to user habits. The first version, so far, is sufficient for the time being.
@kesonan
However, in that case, if you convert too many non-int64 types to int64, would it result in allocating more memory, such as when a struct contains multiple small-sized enumeration values?
hi @kevwan @kesonan
I think we should be rigorous and careful on the mapping issue from database filed type to golang model. At least, can provider a very strict mode to mapping. reasons as below:
-
A value with int64 in golang model, may be overflow when store into a tinyint in database. I think this case is unaccepable who has purpose on high-quality.
-
for below words, I think as a framework, should not cover the not exact case (as below).
in many cases, database developers do not add unsigned constraints to unsigned types.
We should not pay for the unreasonable design of database field types, especially for high-quality microservice frameworks
Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑🤝🧑👫🧑🏿🤝🧑🏻👩🏾🤝👨🏿👬🏿
pls see features: #4062
