[Feature Request] Concrete type WhereIn helpers

[shousper]

We have methods that accept 1 or more lists of values for certain queries, a simple example might be something like this:

func (r *someRepository) FindAllByTypes(ctx context.Context, types []interface{}) ([]*persistence.Client, error) {
	return persistence.Clients(qm.WhereIn("type in ?", types...)).All(ctx, r.db)
}

But.. the types aren't interfaces, they're often just strings or UUIDs, sometimes ints or enums. So we need to write a helper to convert our concrete slices to interface{} an slice. We can't use varargs, because the input values aren't hard-coded or fixed length.

Would it be worth the query mod system supporting these concrete types somehow? Maybe not WhereInString but rather WhereIn("type in ?", qm.InStrings(types)) or maybe the Where could be more powerful by accepting a parameter implementing an In interface of some sort instead?

I understand this would probably look like a breaking change, but I'm hoping you've already got some ideas on this? 😃

[aarondl]

First of all I'm not 100% sure why this would be a breaking change. Sounds like you just want some extra helpers to convert say []string -> []interface{} and []int -> []interface{} etc. No?

[shousper]

Spot on @aarondl.

[louis77]

Something like that:

        names := []string{"bernd", "werner", "urs"}
	namesInterface := make([]interface{}, len(names))
	for i, v := range names {
		namesInterface[i] = v
	}

[shousper]

@aarondl, I guess the breaking change comment was if changes were made to the Where function. I think a simple helper might be enough for now 👌

[aarondl]

This will be superceded by #426

[shousper]

Not sure where to comment as both issues are closed, but I just realised #426 never actually implemented a helper for the IN operator.

Any chance of this getting re-opened until that's done?

Cheers.

[aarondl]

@shousper There's been a separate feature request for them opened here: #570