Custom Go-lang types for DB models (Monetary values) about jet HOT 9 CLOSED

@go-jet thank you for making this change. We now use the decimal branch as our officially supported jet version. It would be great if you merge that branch into develop and eventually do an official release. We decided to use string in our models instead of a third party decimal library. We do the appropriate conversion elsewhere as needed.

FYI we use a bash script wrapper around the jet code generator to replace the types in the models when they are generated. I documented what we do in this gist:
https://gist.github.com/mlaflamm/5093c5877b401f608a1a737fab7b662c

This might be of interest for other jet users.

from jet.

@crazydadz Agreed, make sense.
@mlaflamm Rebased.

from jet.

I've created a new PR that add a test to write a decimal into the database. #62

from jet.

Lossless decimal scan is now included in the latests v2.5.0 release.

from jet.

It is not possible to customize generated model at the moment. This feature will be added later.

But it is possible to create custom model file, and even to combine custom with generated model files.
Also as a go struct field it is possible to use any type that implements Scanner interface.

Assuming table name is my_table, column is money and that you want to retrieve sql numeric type to go integer type, something like this should be possible:

type MoneyType int64  // or some other type 

func (e *MoneyType) Scan(value interface{}) error {
 ...  add implementation
}

type MyTable struct {
    model.MyTable
    Money MoneyType
}

Now it is possible to use MyTable in any place where model.MyTable is used before.

from jet.

We ran into a similar issue. Unfortunately even with your suggestion to use a customised model, the value is converted to a sql.NullFloat64 in qrm/utill.go before being passed to the custom type Scan.

To work correctly, the value must be converted to a lossless decimal type, like ericlagergren/decimal. Using sql.NullString instead of sql.NullFloat64 would likely work too. I am sure this could be implemented in a way that doesn't break projects that use the generated models with float64.

from jet.

Yes, you right, exact decimal types(decimal and numeric) should have been first converted to string.
I've made a quick fix(decimals branch) which enables scan into custom lossless decimal types using customized model types.(sample usage)
Note that scan from decimal and numeric into float64 is disabled on this branch.

from jet.

Would it be possible to base your branch from develop? We would like to try it but we have a strong dependency on #51.

from jet.

I've done a PR (#61) based on your decimal branch that is backward compatible with existing generated models that uses the float64 type. All the postgres tests are passing. This may breaks custom models that defined their own decimal type but paradoxically this may be a good thing if anyone cares about decimal precision.

from jet.