I must say, I'm a bit confused by this e-mail :-) Let's go through this e-mail step-by-step
> The problem with transform the Record is the annoying boilerplate and loss > of fluent style. Yes, unfortunately, Java 8's lambda expressions aren't available yet. Note, though, that jOOQ 2.6.0 will also have a RecordMapper, in addition to the RecordHandler, for a "little" more fluency: https://github.com/jOOQ/jOOQ/issues/1756 > I also just don't like having Record (as an import) all > over the place. It is up to you how far you want to let Record leak into your application. You can immediately transform it into anything else before letting it leave a DAO > I feel like jOOQ's SQL building should be decoupled from its fetching > operations. I have do this in my own library like: But it is decoupled, isn't it? How are the two parts entangled? > parentDao.select() // RootClause<SomeFetcher<ParentBean>> > .where() > .property("test.stringProp").eq("Hello") > .orProperty("test.longProp").eq(1L) > .query() // Here is where The hand off to the "fetcher" happens ie we > are now SomeFetcher<ParentBean> > .forList(); This means that the SQL building API would make a lot of assumptions about how fetched Records would later be mapped onto POJO types. In my opinion, this would couple fetching with SQL building more closely. Additionally, I think it is hard to get the property() and orProperty() "selectors" right, as the ParentBean.class would need to be introspected in order to generate correct SQL, just like in HQL. In fact, why not just use HQL (or CriteriaQuery?). Please note that jOOQ is about the "database-first" way of thinking. Mapping *tables* to beans / POJOs should be a secondary concern, the SQL query and the tables are the primary concern. If you wish to go the other way round, you probably shouldn't use jOOQ. Of course, the jOOQ way of thinking doesn't exclude mapping tables onto beans, but only once the tables are fetched. > I guess what I'm saying is that (IMHO) it seems that the *Step interfaces in > jOOQ should be parameterized with a fetcher ie > SelectWhereStep<T>. [...] >From what you provided, I'm not sure where this is supposed to be going. Could you show me a working API and call-site example illustrating the usefulness of adding such a parameter to all the *Step interfaces? But please note that the various fetchXXX() methods in ResultQuery are just convenience for their corresponding counterparts in org.jooq.Result. Maybe that was the source of confusion? Cheers Lukas
