Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should return value with return type #343

Closed
gxanshu opened this issue Apr 8, 2024 · 1 comment
Closed

Should return value with return type #343

gxanshu opened this issue Apr 8, 2024 · 1 comment

Comments

@gxanshu
Copy link

gxanshu commented Apr 8, 2024

I'm coming from TypeScript environment, and Kysely is by far the best SQL builder in TypeScript. The only 2 things that make it great is is Type safety in SQL query building and return type. Jet done really great job in SQL query building but still i'm struggling to get the Return Type.

What i mean is in Jet we have to first write the query and then have to write a destination variable with proper return type this takes time to develop.

var dest []struct {
    model.Actor
    
    Films []struct {
        model.Film
        
        Language    model.Language
        Categories  []model.Category
    }
}
err := stmt.Query(db, &dest)
handleError(err)

I think if Jet return that variable with proper type then it would be very nice, it can increase developer experience and productivity.

@go-jet
Copy link
Owner

go-jet commented Apr 11, 2024

Hi @gxanshu, I agree that it would be nice, but I don't think it's technically feasible in Go or probably in any other type safe language. It's probably doable for a single table select, but for multiple joined table its much harder. Especially because Go doesn't have such a powerful generics support. Are you saying that Kysely can produce automatically deeply nested destination struct using generics? If that's the case I would love the see an example.

Event if it is technically possible, I don't think it would be desirable. There can be different valid destinations for the same query. Also, for some of the tables(like N:M), you don't want them to appear in the destination. What to do with calculated projections(like COUNT(*))? Where those values will go in the automatic destination? There are probably many more edge cases, where automatic destination would not work.

@go-jet go-jet closed this as completed May 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants