On Sunday, September 23, 2012 5:45:48 AM UTC-4, Lukas Eder wrote:
>
> > I think what I would need out of jOOQ ResultSet mapping are the ability
> to
> > map children from the result set automagically.
>
> If anything is missing right now, you can always write your own.
> Either, you transform the org.jooq.Result (which is nothing but a
> List<Record>) to your own custom type, or you can use jOOQ's
> RecordHandler, which works much like Spring's RowMapper:
> http://www.jooq.org/doc/2.5/manual/sql-execution/fetching/recordhandler/
>
The problem with transform the Record is the annoying boilerplate and loss
of fluent style. I also just don't like having Record (as an import) all
over the place.
I feel like jOOQ's SQL building should be decoupled from its fetching
operations. I have do this in my own library like:
SqlObjectDao<ParentBean> parentDao = new SqlObjectDao<ParentBean>(mock,
ParentBean.class);
// Assume Parent bean is a immutable with a ManyToOne to child bean called
TestBean
// TestBean has two properties stringProp and longProp JPA annotated.
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();
verify(mock).query(
"SELECT parent_bean.id, " +
"_test.string_prop AS \"test.stringProp\", " +
"_test.long_prop AS \"test.longProp\", " +
"_test.timets AS \"test.timeTS\" " +
"FROM parent_bean " +
"INNER JOIN test_bean _test ON _test.string_prop = parent_bean.test
" +
"WHERE _test.string_prop = ? OR _test.long_prop = ?"
, new Object[] {"Hello", 1L}, parentDao.getObjectRowMapper());
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>.
Thus "public interface Select<R extends Record> extends ResultQuery<R>,
TableLike<R>, FieldLike, FieldProvider "
I think would be less bloated and better serving it was:
public interface Select<I> extends TableLike<R>, FieldLike, FieldProvider {
public I query(); // This is where you could hand off to the result
query.
public interface SelectHandoff<K extends Select<I>, I> {
I Handoff(K clause);
}
// etc
}
> > I did this before with result set column "dotted" naming conventions and
> the
> > Jackson ObjectMapper.
> > I was contemplating generating constants from the java beans to make
> this
> > column labels easier ie ( table1.col1 AS
> > "parentBean.childBean.childProperty").
>
> That sounds like a nice idea if you generate SQL from the POJO
> classes. I'm guessing that you somehow know when to "start a new
> parentBean" as opposed to when to "reuse an existing parentBean" and
> append to its childBean list?
>
> > I guess what I'm saying (and I think Lukas is also) is jOOQ does not
> need
> > its SQL generation changed.
> > We just need better ResultSet mapping and maybe some utility libraries
> to
> > help generate the ManyToOne SQL (like the constants mentioned above).
>
> Precisely
>
> > I propose a jOOQ extension (that I already wrote for Spring as a
> RowMapper)
> > that will translate the ResultSet's to a hierarchy of Maps.
>
> Yes, as soon as these data hierarchies are possible for jOOQ to
> handle, the existing Result.intoMap() and Result.intoGroups() methods
> would need to be adapted (the latter is being implemented for jOOQ
> 2.6.0)
>
> > BUT I don't see where I can inject custom data conversion (ie Calendar
> to
> > Timestamp) etc.
>
> This is documented here:
>
> http://www.jooq.org/doc/2.5/manual/sql-execution/fetching/data-type-conversion/
>
>
> And here:
> http://www.jooq.org/doc/2.5/manual/code-generation/custom-data-types/
>
> > I think loading ManyToOne paths would fit most peoples needs considering
> > most people with modern Web Apps are returning JSON which is just a
> > hierarchy of maps (except for the OneToMany lists). This could be done
> > outside the query generation and in the result set handling.
>
> That is an interesting thought. In fact, jOOQ's Result.formatJSON()
> and Result.formatXML() methods should be adapted accordingly, once
> arbitrary "grouping" of Result objects is implemented. I wish Java 8
> was available already. These transformations could be expressed quite
> neatly with lambda expressions...
>
> Cheers
> Lukas
>
