Hello Dileep, Thanks for your benchmark
> Since I already have TITLE in the select part, why should I repeat myself > and add it in the fetch part. With Querydsl that issue is not there since > they have done away with select. Yes, indeed. jOOQ's fetching of List<T> is a bit more verbose than that of QueryDSL / JPA / Hibernate / LINQ. As you noticed, this is due to some redundancy between the select(...) and fetch(...) methods. jOOQ's current API certainly makes sense, if you're intending to use one of the various other fetch methods, which do not take a Field<T> as an argument. But it would probably make sense to follow QueryDSL's example in this case and allow for specifying projections in the fetch(...) methods. I'll file this as feature request #1402: https://sourceforge.net/apps/trac/jooq/ticket/1402 I'll have to think about whether such queries would have to be initiated with from(...) rather than with select(...). There are some remote use cases, where the current API is better than that of QueryDSL. Think about UNIONs or DISTINCT keywords. Sometimes, you want to remove duplicates based on 2-n fields, while fetching only one of them. > The time taken by both queries to execute (including fetch time) is > significant (24 vs 46ms). Yes, that overhead should be avoided if possible. > Is there a better way of doing it. Currently, you'll have to repeat yourself in order to fetch List<T>. Cheers Lukas
