>>> So another approach would be to add >>> >>> int Query.fetchCount() >>> >>> to the API. The implementation should build SQL which ignores anything >>> between "select" and "from". The implementation of this would be in >>> the dialect. >> >> I guess I could live with such a solution. > > One of the recurring requirements that I have is a paged display with a > result size count, so varying a query from "give me the result columns" to > "just give me the result count" is something that I could make use of. > > I suspect I'm not alone with this use case.
You're certainly not alone with this. However, beware that it is always better to use window functions, where available: COUNT(*) OVER(). Executing the same query twice for paging can be quite costly in the DB. > Aside note: I'm not sure whether "fetch" is the right terminology here, it is > ringing some unappropriate overtones for me (in the sense of "page fetching" > and "fetch limits"). I'd have designed it as a query transformer that takes a > query and returns its SELECT COUNT(*) variation (so it can be reused, > prepared with values, etc). "Fetch" is a well-established term in the jOOQ API: http://www.jooq.org/doc/2.6/manual/sql-execution/fetching/ So, "fetchCount" is the best choice here, as the Select variation is actually executed and a Result is fetched. The term "FETCH" is also well-established in the SQL standard. See §13.3 <fetch statement> from http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt It is used to fetch data from a cursor. Other terms such as the ones you mentioned, are probably derived from this. Cheers Lukas -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
