0

I want to use the Scan() function from the sql package for executing a select statement that might (or not) return multiple rows, and return these results in my function.

I´m new to Golang generics, and am confused about how to achieve this. Usually, we would use the Scan function on a *sql.Rows and provide the references to all fields of our expected 'result type' we want to read the rows into, e.g.:

var alb Album
rows.Scan(&alb.ID, &alb.Title, &alb.Artist,
            &alb.Price, &alb.Quantity)

where Album is a struct type with those five fields shown.

Now, for the purpose of not writing a similar function N times for every SQL table I have, I want to use a generic type R instead. R is of generic interface type Result, and I will define this type as one of N different structs:

type Result interface {
    StructA | StructB | StructC
}

func ExecSelect[R Result](conn *sql.DB, cmd Command, template R) []R

How can I now write rows.Scan(...) to apply the Scan operation on all fields of my struct of R´s concrete type? e.g. I would want to have rows.Scan(&res.Field1, &res.Field2, ...) where res is of type R, and Scan should receive all fields of my current concrete type R. And do I actually need to provide a 'template' as argument of R´s concrete type, so that at runtime it becomes clear which struct is now relevant?

Please correct me on any mistake I´m making considering the generics.

PandaPhi
  • 157
  • 11

1 Answers1

2

This is a poor use case for generics.

The arguments to the function sql.Rows.Scan are supposed to be the scan destinations, i.e. your struct fields, one for each column in the result set, and within the generic function body you do not have access to the fields of R type parameter.

Even if you did, the structs in your Result constraint likely have different fields...? So how do you envision writing generic code that works with different fields?

You might accomplish what you want with a package that provides arbitrary struct scanning like sqlx with facilities like StructScan, but that uses reflection under the hood to map the struct fields into sql.Rows.Scan arguments, so you are not getting any benefit at all with generics.

If anything, you are making it worse, because now you have the additional performance overheads of using type parameters.

blackgreen
  • 34,072
  • 23
  • 111
  • 129
  • Thanks for your answer. If I want to solve it without the external sqlx package, should I instead use switch to distinguish between the different possible struct types? so e.g. switch { case StructA: ... case StructB: ... case StructC: ... in this case, which would require to check the type of R, or better variable 'template' – PandaPhi Apr 19 '22 at 10:08
  • @PandaPhi yes a type switch might work, but then you are using type parameters for exactly no advantage ~ except restricting the type set of `R`, but the benefit in still unclear – blackgreen Apr 19 '22 at 10:11
  • Yes, I meant without using R. I wanted to use generics but haven´t found an appropriate use case yet. I guess, for now I´ll provide the template of any type as parameter, then switch case check its type. Unfortunate that there is no way to get around this boilerplate code without using a library such as sqlx – PandaPhi Apr 19 '22 at 11:45