Replies: 5 comments
-
You can easily create a type that embeds sql.Null* and make that type implement all the Marshallers and Unmarshallers that you need. Or, if you only need json and don't want to write any additional code, you can the null package to handle this for you. |
Beta Was this translation helpful? Give feedback.
-
Hi @euller88, what do you suggest in case I do not want interface to have sql specific types. As there might be other nosql implementation |
Beta Was this translation helpful? Give feedback.
-
@dharmjit I do not know what to do, but I have a suggestion. Try to override every type you expect to receive to either |
Beta Was this translation helpful? Give feedback.
-
I think a perl one-liner to replace sql.NullString with *string is the way I'm going to go, no intermediate steps or extra code needed. But thats just me, I'm still really impressed with the utility of sqlc and wish I had something like this twenty years ago. |
Beta Was this translation helpful? Give feedback.
-
I would very much like for this to be a feature as well. Happy with sqlc in many ways, good work. For anyone reading this thread, I added the following to my
Will probably be solved by #1571. |
Beta Was this translation helpful? Give feedback.
-
I'm not doing anything too hardcore with Sqlite, I was able to generate compatible code with sqlc by manually changing datetime to timestamp in the table definitions I fed to sqlc.
The structures I read in from the database are being shared with several packages (json, html/template, etc) which are not aware of sql.NullString and friends, so my two cents is that it would be nice to have an option to emit *string (etc) instead of sql.NullString, sql.NullInt, etc. since the database/sql module already works with them seamlessly.
Otherwise I'm really impressed with sqlc and the code it generated, thank you for a great tool!
Beta Was this translation helpful? Give feedback.
All reactions