You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When working with structs, struct tags are used to add additional information to a field. This is for example very common when using validation packages. But currently there is no way to add additional struct tags to take advantage of this.
I think it would be a great idea to add a comment syntax just like the -- name:NameForQuery for table columns.
A possible option to express these custom struct tags would be to write create table statements like this:
Has anyone pickup this enhancement yet? It would be useful for generating fake data on model fields. If not I would like to give it a try with proper PSR predicated.
I think this might also need something like custom_tag_value for instances like validate where consumers want to set a custom value. Otherwise, the default would be whatever the json_tags_case_style is set to (otherwise the default format).
Further to the above, this wouldn't override json tags, it would be in addition to emitting json tags.
It seems to me that the conversation around including these in the schema is not the right place for this. Struct tags are really just a go concern, so possibly even including it in the definition of the go_type in the override might be a better place.
@kyleconroy can we hope to see a feature like this in the foreseeable future? In my project, we started using Gorm way back in time, and it has been something we have been considering moving away from (towards sqlc). However, we rely on some 3rd party code that uses Gorm under the hood, so completely running away from it isn't feasible at the moment.
If there were a way to let sqlc generate our Gorm-compatible models, this would be fantastic. It's the one thing that's stopping us from getting all in on sqlc.
The only other alternative is still keep two copies of each model, which isn't that bad, but possibly error-prone.
Activity
huangc28 commentedon Aug 14, 2020
Has anyone pickup this enhancement yet? It would be useful for generating fake data on model fields. If not I would like to give it a try with proper PSR predicated.
fr3fou commentedon Dec 31, 2020
Is there a way to achieve this now?
I want to ignore the password field on my user struct, like so
ciazhar commentedon Oct 26, 2021
up
tamoore commentedon Feb 28, 2022
@kyleconroy Would you be open to a solution that utilised the config overrides?
Something like the following:
I think this might also need something like
custom_tag_valuefor instances likevalidatewhere consumers want to set a custom value. Otherwise, the default would be whatever thejson_tags_case_styleis set to (otherwise the default format).Further to the above, this wouldn't override json tags, it would be in addition to emitting json tags.
It seems to me that the conversation around including these in the schema is not the right place for this. Struct tags are really just a go concern, so possibly even including it in the definition of the
go_typein the override might be a better place.preslavrachev commentedon Mar 20, 2022
@kyleconroy can we hope to see a feature like this in the foreseeable future? In my project, we started using Gorm way back in time, and it has been something we have been considering moving away from (towards sqlc). However, we rely on some 3rd party code that uses Gorm under the hood, so completely running away from it isn't feasible at the moment.
If there were a way to let sqlc generate our Gorm-compatible models, this would be fantastic. It's the one thing that's stopping us from getting all in on sqlc.
The only other alternative is still keep two copies of each model, which isn't that bad, but possibly error-prone.
austincollinpena commentedon Mar 21, 2022
I agree that this seems like a good thing to add to the configuration file.
josharian commentedon Apr 25, 2022
We're facing this right now as well. I'm game to work on it, if we can get to an agreement about the design.
FWIW, I would prefer adding custom struct tags to the config file, using something like:
austincollinpena commentedon Apr 25, 2022
I like that design
all: add support for custom Go struct tags
josharian commentedon Apr 25, 2022
Implemented in #1569 if anyone wants to kick the tires.
all: add support for custom Go struct tags
add support for custom Go struct tags (#1569)