scany
scany copied to clipboard
FR: config to ignore columns not found in destination type
Hi, Thanks for building this!
We have an SQL query that's part static (e.g. select * from users) and part dynamic (e.g. multiple joins with user-defined tables, the number of joins is decided in runtime). We have no problem scanning the "dynamic" columns by ourselves, but we hoped to use scany to scan the static part, so for example the following would be great:
type User struct {
...
}
type Result struct {
User
DynamicStuff []DynamicData
}
...
...
scanner := dbscan.NewRowScanner(...).IgnoreUnknownColumns()
// we use per-row scanning interface so we can do our own scans for the dynamic part.
for rows.Next() {
var user User
scanner.Scan(&user)
// .. our own scanning for the dynamic part ..
d := scanDynamicStuff(&rows)
result := Result{user, d}
}
Please let me if this makes sense - we can do a PR as well.
Hey! It should be pretty easy to implement. I see two options here:
- Add configuration option on the global API level like
AllowUnknownColumns
.
customAPI := dbscan.NewAPI(AllowUnknownColumns)
Some people might want to have more forgiving scanning to be able to write SQL like SELECT * FROM ...
.
2. If you don't want to lose the default strictness of scany with the global API option, we could Introduce RowScannerOptions
similar to API options but on the RowScanner
level and again add AllowUnknownColumns
to pass.
scanner := dbscan.NewRowScanner(rows, AllowUnknownColumns)
// we use per-row scanning interface so we can do our own scans for the dynamic part.
for rows.Next() {
var user User
scanner.Scan(&user)
// .. our own scanning for the dynamic part ..
d := scanDynamicStuff(&rows)
result := Result{user, d}
}
I like these options!
Great! Would you be interested in proposing a PR?
Thanks a lot for writing this library, I have used it every day for two years professionally and never had a single issue with it. It does what it says on the box and simply works!
Top the topic at hand: should this issue be closed? The merged PR seems to solve it.
@andersarpi, thank you for your warm words!
You are right. We can close this one. Thanks!