db struct tags not mapping to column names

[kaihendry]

For example the gen result https://github.com/unee-t/tables-to-go/blob/bug1/tests/Persons.go#L10 is:

IdPerson             int            `db:"IdPerson"`

I expected it to be

IdPerson                int            `db:"id_person"`

Better still would (probably) be:

ID                int            `db:"id_person"`

I'm aware of -format o but I don't want my struct names to have underscores in them! :cry:

Please see:

• https://github.com/unee-t/tables-to-go/blob/bug1/tests/Makefile
• https://github.com/unee-t/tables-to-go/blob/bug1/tests/docker-compose.yml

This is how I gen the output.

[fraenky8]

@kaihendry what is the original name of the columns? I recently discovered a bug that the tag doesn't contain the origin column name and fixed it straight away (#9).

The tags should contain the columns original name otherwise the sql driver is unable to map the structs to the table later.

Better still would (probably) be: ID int `db:"id_person"`

What if there are multiple columns starting with id_ - eg. a foreign key - then the tool could not determine what ID field it should generate. This would lead to duplicate ID struct fields which are not allowed by golang. Therefore I prefer that this tool only focusses on the task to create structs from existing tables and their original column names instead of guessing what a good struct-field name would be for a particular column.

[kaihendry]

The original name is id_person.

Btw I ended up with

ID                   int             `db:"id_person" json:"id"`

in my own edits https://github.com/unee-t/enterprise-rest-api/blob/master/model.go#L13

I switched things to pointers so that empty values will not appear in the JSON response. :grimacing:

[fraenky8]

The original name is id_person.

OK this is fixed by #9 then 👍

I switched things to pointers so that empty values will not appear in the JSON response. 😬

haha yeah this is one way to make it work too! 😄

So I close this issue then - thanks for reporting & discussing 👍

[kaihendry]

Thanks Frank. My goal is to not output empty values in my "RESTful" JSON responses. The only way I have figured to do this is to make the types pointers: https://play.golang.org/p/twlj-QhK-tG

So I am curious why you don't use pointers? Why are some types "string" and others "sql.NullString"?

https://media.dev.unee-t.com/2019-03-30/types.mp4

[fraenky8]

Hi sorry for alte answer, weeekend is always very packed.

Ok I saw that you stick to the pointer solution now - which is not wrong at all. As the answer at SO (https://stackoverflow.com/questions/55437279/sql-nullint64-to-json) explained, the sql.Null* structs exists to map the DB NULL to the language (golang) zero/null/nil value.

So I am curious why you don't use pointers? Why are some types "string" and others "sql.NullString"?

The tool uses string for columns that are declared with NOT NULL and sql.NullString otherwise.

Since this tool was one of the first things I built with golang I thought sticking to the standard library (which uses these sql.NullString structs) would be a good way. But I also see the need for some people to use pointers instead. I will open a issue for that I can work on when I find time.

One more thought tho: Mapping the DB NULL to the programming langugage and represent your data as JSON are in my opionion two different concerns. So as people pointed out at SO there are pro and cons using the struct and the pointers. If you using the struct solution there are libraries (https://github.com/guregu/null, https://github.com/gobuffalo/nulls, ...) written by people who had the same problem with pretty JSON which basically alias the sql.NullString and having own marshal/unmarshal functions of it so that JSON has a flat representation.

[kaihendry]

Thank you! I didn't know about those null alternatives.

My application isn't performance sensitive, so I wonder if I need to be that worried about using pointers. Are there other reasons not to use pointers besides the allocation delay?

[fraenky8]

Are there other reasons not to use pointers besides the allocation delay?

Well using pointers to primitive is not very idiomatic go I guess. It also makes the usage ugly: https://play.golang.org/p/BvjC_pdUobv