> For example changing how ResultQuery does "intoPOJO" requires quite a bit of > work (subclassing) all those steps. > > I guess what I'm saying is that I cannot change how ResultQuery works and > its included in the SQL building process. > > So what I mean is Select<ResultQuery> s = should build me a select that will > hand off to ResultQuery;
OK, I understand now. Well, I'm not sure if such a "fetcher" type should be part of the DSL API for these reasons: 1. The separation I've mentioned would be breached 2. This would be a major incompatible change 3. The importance of the change would be in no proportion to the added value Anyway, jOOQ has frequent releases with new fetch methods in every release. I guess that waiting for the jOOQ 2.6.0 RecordMapper will be your best option here: https://github.com/jOOQ/jOOQ/issues/1756 An example: ----------------------------------------- public class MyMapper<E> implements RecordMapper<Record, E> { final Class<E> type; public MyMapper(Class<E> type) { this.type = type; } @Override public E map(Record record) { return myOwnPOJOMapping(record); } } // And then List<BaseBean> result = create.select() .from(MY_TABLE) .where(...) .fetch(new MyMapper<>(BaseBean.class)); ----------------------------------------- That should probably be fluent enough for you...? In the mean time, try using the RecordHandler, which is a bit less "fluent" ----------------------------------------- public class MyHandler<E, R extends Record> implements RecordHandler<R> { final Class<E> type; final List<E> result; public MyHandler(Class<E> type) { this.type = type; this.result = new ArrayList<>(); } @Override public void next(Record record) { result.add(myOwnPOJOMapping(record)); } public List<E> getMyResult() { return result; } } // And then List<BaseBean> result = create.select() .from(MY_TABLE) .where(...) .fetchInto(new MyHandler<BaseBean, MyTableRecord>(BaseBean.class)) .getMyResult(); ----------------------------------------- > What I would prefer jOOQ did is help me compose or build SQL statements that > I can than pass around. > My example was trying to show how I build a SQL AST (abstract syntax tree) I > then pass that AST off to the parameterized contained fetcher. > The fetcher/executor than uses the visitor pattern to turn that SQL into > real SQL and then execute. Introducing such features in jOOQ is out of scope for 3.0, as the roadmap is already quite full. > Actually thats exactly the way I want to go... I want you to give me some > nice valid SQL but I execute and do the POJO mapping myself. This: "but I execute [...] myself", is news to me... How would you want to do your own custom execution, while at the same time remain within jOOQ's fluent API? > And yeah I can do the POJO mapping sort of myself but its not elegant, and > breaks the fluent chain. I just think you want too much from the jOOQ API. :-) Instead you should implement some of the "missing" things at the call-site > I could write a custom Record Handler but how can I elegantly plug that in > for all my factories? By passing it manually (see the example above). Or write your own Executor: ----------------------------------------- public class Executor<E, R extends Record> { final Class<E> type; public Executor(Class<E> type) { this.type = type; } public List<E> fetch(ResultQuery<R> query) { query.fetchInto(new MyHandler<E, R>(type)).getMyResults(); } } ----------------------------------------- > So while: > https://github.com/jOOQ/jOOQ/issues/1756 is nice I still have to pass in > the handler all over the place. Yes. You will have to understand, that I cannot add all possible types to the API. Other users may want <E>, <T> (no pun intended), etc. If everything goes into the fluent API, we'll end up with Select<I, H, E, T, R extends Record, T2 extends Table<R>> To wrap things up: The "fetching mode" should not be a first-class citizen in the DSL API, as the DSL API is about SQL building, not about fetching. Cheers Lukas
