DT
Drizzle Team11mo ago
nk

Dynamic select with types?

Does anyone know how to do this correctly? Example:
async t<T>(select: Something) {
return db.select(select).from(table);
}

const data: { id: number; }[] = t<{ id: number; }[]>({ id: table.id });
async t<T>(select: Something) {
return db.select(select).from(table);
}

const data: { id: number; }[] = t<{ id: number; }[]>({ id: table.id });
8 Replies
nk
nkOP11mo ago
More specifically, how do I make the type used by select(), I guess would be a better question. And get the return type of said query. I want to be able to use one function for all gets on a table, but without having to lose types when I only want certain fields, basically.
Angelelz
Angelelz11mo ago
I don't really like this type of abstractions But it can be done, you just need to make Something generic..
cal
cal11mo ago
what do you dislike about it?
francis
francis11mo ago
what does it get you? you effectively have to strongly type it to constrain the input table type (or selection type) because each is tied to the other if you want to select a certain group of columns every time, define that elsewhere and pass it into select; if you want to have a certain where condition every time, define that condition elsewhere too the actual drizzle query methods are the least onerous parts that you'd need to abstract out, IMO I guess I'm saying this seems like a weird inbetween middle level of abstraction that is not useful. either abstract out the query inputs and use those, or abstract out the entire query itself to a reusable "get me X thing" function, but ending up in the middle is a bunch of extra work for not that much gain
Angelelz
Angelelz11mo ago
I take it a bit further, I put all the methods that I want in a interface, say DataSource and then create a class that implements it. I define the type that I want in the end, before implementing the query. I keep all database logic behind the interface, and the application can only interact with the database through that interface. I love that pattern because I can refactor my queries however I want and the application never notices, as long as I deliver what the interface has defined
cal
cal11mo ago
yeah this is definitely a valid pattern. I was just looking into the patter OP posted for a usecase where I would select users accounts with sensitive data and wanted to create something like
withUnsecure(user(id))
withUnsecure(user(id))
your approach would be to create - unsecureUser - user in the interface and the some wrapper like user(id, unsecure) is that correct?
Angelelz
Angelelz11mo ago
I'm not totally sure I understood. But if I wanted to get the user with sensitive data, I would create a different method for what I want
Want results from more Discord servers?
Add your server