#16 Silly Column Names....

Closed
opened 2 years ago by robertmeta · 3 comments

One of the first DBs I played with has a lot of very silly column names... like type, date which tried to generate

   if _, ok := req.Form["type"]; ok {
              type := req.FormValue("type")

which won't work, I think there needs to be a "work around" for go keywords in column names.

One of the first DBs I played with has a lot of very silly column names... like `type`, `date` which tried to generate if _, ok := req.Form["type"]; ok { type := req.FormValue("type") which won't work, I think there needs to be a "work around" for go keywords in column names.
otremblay commented 2 years ago
Owner

Argh, had not thought about that at all.

If this only occurs in the http handlers, then it should be okay to just prepend the var with something like form_ or something (in the template, I mean). I'll test that more in depth tonight.

Argh, had not thought about that at all. If this only occurs in the http handlers, then it should be okay to just prepend the var with something like form_ or something (in the template, I mean). I'll test that more in depth tonight.
robertmeta commented 2 years ago
Poster

This list of banned identifiers is:

break default func interface select case defer go map struct chan else goto package switch const fallthrough if range type continue for import return var

This list of banned identifiers is: break default func interface select case defer go map struct chan else goto package switch const fallthrough if range type continue for import return var
otremblay commented 2 years ago
Owner

I'm thinking that in most cases, I'd probably want this case to not happen at all, with a general solution that would make the generated code be uniform. For exported fields it's fine, as they need to be capitalized, so it's really just for local vars, in principle. Mostly because I was too lazy to make the fields private on the structs.

I'd have run into this in the future, when I want to be able to generate nullable values for stuff like strings (where it would make more sense to have the thing generate accessors for fields, and then have a private unexported field).

I'm thinking that in most cases, I'd probably want this case to not happen at all, with a general solution that would make the generated code be uniform. For exported fields it's fine, as they need to be capitalized, so it's really just for local vars, in principle. Mostly because I was too lazy to make the fields private on the structs. I'd have run into this in the future, when I want to be able to generate nullable values for stuff like strings (where it would make more sense to have the thing generate accessors for fields, and then have a private unexported field).
Sign up for free to join this conversation. Already have an account? Sign in to comment
No Milestone
No assignee
Loading...
Cancel
Save
There is no content yet.