[grey-area]

Have you considered another mechanism apart from field tags for relating fields to the db (for example a function for marshalling?). It's starting to look like you're creating a dsl stuffed into struct field tags as strings, which gets ugly if it is complex. This is one part of go I'm really not keen on for this reason.

[aodin]

In https://github.com/aodin/sol#sol I separated the table schema, which is a function, from the destination / receiver structs. This approach allows you to build tables programmatically and do condensed selections, such as all IDs into a []int. However, this process still has to match database columns to struct field names for most selections.

[aacanakin]

There is a table api in qb much like yours. See https://github.com/aacanakin/qb/blob/master/table_test.go. The session api converts tags into table object. I really like the column definitions. Maybe I can convert the definition implementation like you.

[aacanakin]

I'm also not happy to add tons of tags in struct fields. Can you provide an example on how to do that? What I understand is to have a function inside the struct namely like "map" and define the constraints there. I think we can do this in the next milestone of qb. Can you open an issue about this? The github repo is https://github.com/aacanakin/qb

[grey-area]

I just use a function taking the row from the db in the model and creating the model from that. It avoids tags and reflection at the cost of some verbosity.