Field insertion for Select

[robfig]

One thing that seems like it could become problematic is:
http://godoc.org/github.com/coopernurse/gorp#DbMap.Select

"Returns an error if one or more columns in the result do not match"

I think the common case will be someone writing

type Model struct {
  // many fields
}
dbm.Select(&models, "SELECT * FROM models WHERE ...")

Presently, as soon as a field is added to the table, the Select will start returning errors. This requires the developer to type out the entire field list for every select to be correct, otherwise there is no way to alter the table without trouble.

Two solutions could be:

• Don't return an error if you don't have a place for a returned column (bad, but easy)
• Provide a syntax for inserting the list of fields that you expect (better)

The latter could work like this:

dbm.Select(&models, "SELECT ... FROM models")

or

dbm.Select(&models, "SELECT {} FROM models")

and that could be replaced by the list of fields expected in type Model.

[coopernurse]

Sorry I never commented on this @robfig . I like your latter examples (I don't have a strong opinion on using ... vs {}).

I would gladly merge a PR that implemented this.

Note that I'm starting to use a develop branch, so if you implement this please do it on a feature branch, and I'll merge it to develop.

thanks!

[robfig]

Hm, thinking about this again, that proposal transfers the concern from adding a column to the DB to adding a column to the struct. I suppose in the struct you can at least make a new field un-exported, or add a db="-" tag..

What I've been doing is just explicitly writing out the fields, always, and it's not really so bad. And it is the only way it could work when you select derived columns, anyway. Maybe that is the thing that should be encouraged..

[vadimg]

@coopernurse @robfig Why do you consider not returning an error if you don't have a place for a returned column "bad"? There's a very clear way to proceed if you have more columns than you need: just ignore the extra ones. I can only see one possible downside to this: It could potentially hide bugs in your code, during development. You might be wondering why a certain struct field is not being filled, and gorp would give you no reason as to why. In development, returning an error might be preferable.

But in production, returning an error (and halting the table mapping) is terrible! It means that if programmers aren't careful with every sql query they write, it could cause production downtime in between db migrations and code pushes. I think this is unacceptable, and I have a simple solution:

For the case of "more columns than you need", gorp would try to map the rest of the columns onto the struct and at the end, return a different type of error-implementing struct that could be checked in the application code and ignored if desired.

[vadimg]

I created this pull request for this issue: #188

[GeertJohan]

#188 was merged. Closing this issue.

[GeertJohan]

#188 didn't address the initial request, which is related to #133.