Allow multiple tag names

[snikch]

Note This PR isn't actually ready for merge since it updates the main package to use my fork

Hey there,

One of the use cases that I have for field names is the idea of generally using the json tag, but needing to override it on occasion for data that should be retrieved from the db, but not marshalled to json. By adding multiple tag support to reflectx I can save myself managing two tags.

For example, most of our data is encrypted with a per row nonce. We don't want to expose that nonce, but also don't want to expose the nonce via json. By using json tags for most fields, but using the db tag when it's available, I can easily provide this functionality.

type MyStruct struct {
  Name string `json:"name"`
  Nonce string `json:"-" db:"nonce"`
}

// My mapper
myDBClient.Mapper = reflectx.Mapper("db", "json")

Does this seem like something you'd like to support? If so we can talk about the implementation - my current one doesn't support multiple tags when using a mapper func - but a setter could be used to adjust or append to the tag names. It just seemed easiest to add a variadic parameter to the reflectx.Mapper function so that the api was backwards compatible.

[elithrar]

Note that if you checkout a new branch within your GOPATH, make your
changes, and then go install ./... you don't have to rewrite the imports.

On Fri, Mar 4, 2016 at 3:26 PM Mal Curtis notifications@github.com wrote:

Note This PR isn't actually ready for merge since it updates the main
package to use my fork

Hey there,

One of the use cases that I have for field names is the idea of generally
using the json tag, but needing to override it on occasion for data that
should be retrieved from the db, but not marshalled to json. By adding
multiple tag support to reflectx I can save myself managing two tags.

For example, most of our data is encrypted with a per row nonce. We don't
want to expose that nonce, but also don't want to expose the nonce via
json. By using json tags for most fields, but using the db tag when it's
available, I can easily provide this functionality.

type MyStruct struct {
Name string json:"name"
Nonce string json:"-" db:"nonce"
}
// My mapper
myDBClient.Mapper = reflectx.Mapper("db", "json")

Does this seem like something you'd like to support? If so we can talk
about the implementation - my current one doesn't support multiple tags
when using a mapper func - but a setter could be used to adjust or append
to the tag names. It just seemed easiest to add a variadic parameter to the

reflectx.Mapper function so that the api was backwards compatible.

You can view, comment on, or merge this pull request online at:

#212
Commit Summary

• Allow fallback tag names

File Changes

• M bind.go https://github.com/jmoiron/sqlx/pull/212/files#diff-0
  (2)
• M named.go https://github.com/jmoiron/sqlx/pull/212/files#diff-1
  (2)
• M reflectx/reflect.go
  https://github.com/jmoiron/sqlx/pull/212/files#diff-2 (37)
• M reflectx/reflect_test.go
  https://github.com/jmoiron/sqlx/pull/212/files#diff-3 (22)
• M sqlx.go https://github.com/jmoiron/sqlx/pull/212/files#diff-4
  (2)

Patch Links:

• https://github.com/jmoiron/sqlx/pull/212.patch
• https://github.com/jmoiron/sqlx/pull/212.diff

—
Reply to this email directly or view it on GitHub
#212.

[snikch]

@elithrar You mean in the main github.com/jmoiron/sqlx package? If so, I totally get that, but in the meantime I'm using this code in production so need to be able to retrieve from source control at the correct locations.

[jmoiron]

My first impressions:

• this is a somewhat niche use case
• it's adding complexity for convenience rather than making something new possible
• the resulting code is less clear than just using a single tag consistently, even if that's repetitive

While the reflectx.Mapper("db", "json") semantics don't seem too difficult (prefer db, fallback to json if available), I think it hurts readability. For example:

type s struct {
    Y int `db:"-"`
    X int `json:"-"`
}

So I'm not sure I'm 100% on board, but I'm willing to be persuaded since you've had more experience with this problem and this particular solution!

[snikch]

I understand your concerns, and it is definitely fitting a specific implementation into the current mapper model. An alternative would be to make a sqlx.Mapper interface, and then consumers are able to provide their own code as required?