Hello Sergey
> 1. We have operation that executes select query and do pagination logic.
> public static <T> SearchResult<T> executeSearch(Class<? extends T>
> clazz, SearchParameters params,
> SelectQuery selectQuery,
> SelectQuery countQuery);
> [...]
Have you considered using analytical functions for the count? I.e.
- Factory.count().over()
- Factory.count().over().partitionByOne()
The second one is equivalent to the first one, but more expressive.
That could save you the extra round-trip for the count query.
Specifically for complex execution plans, Analytical functions might
prove to be much more performant compared to separate query
executions.
> It's not clear how to extract configuration, "from" and "where" clauses
> from SelectQuery (using jOOQ API, w/o reflection).
> SelectQueryImpl is package visible and it contains package visible
> attachments..
Currently these objects do not expose their internals. There is a
pending feature request to open up the non-DSL API in order to make
such introspection easier (I can't find it right now). It should be
planned for jOOQ 3.0, as it might have quite some impact on the API.
> 2. We receive selectQuery in executeSearch operation ("select field1,
> field2, field3 ... from table ..") and want to exclude some fields from
> field set. Now selectQuery.getSelect() returns modifiable list of fields and
> we can add/remove elements. However we are not sure, that this collection
> will be modifiable in the future.
You are right, you shouldn't expect this method to stay that way. The
aforementioned introspection features will clear things up, but
probably not in jOOQ 2.x.
Another issue here is the fact that jOOQ's API is not very consistent
with QueryParts being mutable vs. immutable. This inconsistency is
documented here:
http://www.jooq.org/doc/2.5/manual/sql-building/sql-statements/dsl-and-non-dsl/#N1068F
