> 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/ > 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
