Why not use From Select instead of Select From

[danicruz0415]

Hi!
I know this may or may not sound dumb but, why not have the option to use from().select() instead of select().from()?

I explain:
I know that drizzle is design as a thin layer over SQL, and also that the syntax is meant to be SQL like, and in SQL we do SELECT a, b, c FROM but, in a chain like syntax, where the types are passed from left to right, I think it makes more sense to first say "where am I going to read the information from" and then "what am I going to read". For example: Let's say that I have a user table and a table user_status table such that each "user" has a "status". I could try to select the following

return await Database.select({
    email: User.email,
    status: UserStatus.description
}).from(User); // Missing join this will error

So when this gets executed, it throws an error (as expected), and the error is very self explanatory: "Your 'status' field references a column 'user_status'.'email', but the table 'user_status' is not part of the query! Did you forget to join it?"

❗But this is still a runtime error. The type system could not catch it because the list of selected elements comes before the list of tables I will retrieve information from, thus it cannot possibly validate that this list only includes fields that are available.
If this instead was:

return await Database.from(User).select({
    email: User.email,
    status: UserStatus.description // error
})

or maybe

return await Database.from(User).select([
    User.email,
    UserStatus.description
])

I am not a typescript expert, but I believe a type could be set such that the select statement only accept fields that are in the from() or in a join() clause, in the same way as in .update().set() set() only accepts fields in the table given to update() (although a bit more complex because of the joins but I think its achievable with generics and unions) because whatever the from() returns to the select is aware of the columns available to be selected.

The current syntax works very well, and the errors are clear, but I think this might improve the type safety and make this errors "compile time" errors like TS is great for. And it might not be a huge change as the compiled SQL would be the same (maybe, hopefully 🙈).
Just an Idea that occurred to me, what do you guys think?

PS: thanks so much for this project, great library 😎

[petejodo]

FYI this is discussed here

[danicruz0415]

Thanks, ill close this one, I see the one you link is closed, maybe that's why I did not find it. I hope they reopen the other one, I think it makes more sense the way its proposed.