Hi Robert, That's an interesting use-case you have there. If I understand you correctly, instead of using a RecordMapper that transforms the entire Result, you had rather transform each column individually, and you'd like to supply only one-way conversion, unlike org.jooq.Converter, which requires that you implement both ways, right?
I don't think that this is generally against the jOOQ way. It's just a way of doing things that we might not have thought of, yet. The DefaultRecordMapper indeed isn't versatile enough to be enhanced in this way, but as I told you in the other discussion, you have an option to register your own RecordMapper to replace the DefaultRecordMapper. This is documented here: http://www.jooq.org/doc/latest/manual/sql-execution/fetching/pojos-with-recordmapper-provider/ You can also apply your own record mapper on a per-query basis, such as: DSL.using(configuration) .select(USERS.ID, {complex case}) .from(USERS) ... .fetch() .map(r -> your conversions here); Attaching such a lambda to the column expression itself will leave a lot of open questions, such as: - What happens to the generic type <T>? Is it applied also to the Select<Record2<T1, T2>>? - What happens with these lambdas when you use such a SELECT statement as a derived table or a nested select? - Can we really do without the Class<B> or Class<V> literals? - What is "b" and how do we know its type (the bean type, I suspect)? I personally prefer to leave this one-way conversion out of the SELECT clause and move it to the FETCH clauses... Also, the bean mapper does not look to be super efficient. Yes, it uses reflection. The lookup of reflection information is cached in your Configuration, but the actual call to the setters are still done via reflection. Explicit mappers will always perform better. Note that one thing that we will be thinking about is to allow for the ability to register "fallback" converters: https://github.com/jOOQ/jOOQ/issues/3896 This means that you can register default org.jooq.Converter types for any combination of <T> and <U> types. In your case, that might be <T = String>, <U = UserStatus>. Of course, there might be other ideas as well Best Regards, Lukas 2015-01-06 23:51 GMT+01:00 Robert DiFalco <[email protected]>: > I have a dynamic query builder, it may join a couple of tables and let the > user select what fields show up in the returned Record. Some of these > fields may use default converters and others may use more complex > conversation (like the string result of a CASE being turned into an Enum). > > What's the simplest way to do this in JOOQ? What I'd like to be able to do > is add a lambda to each "thing" I put in select. I would be able to do this: > > selects.select(USERS.ID, (b, v)->b.setId(v)); > selects.select( {complex case}, (b, > v)->b.setStatus(UserStatus.valueOf(v)); > ... > > And so on. I could define these up front. I can't really do this with JOOQ > and that's okay because I want to do things the JOOQ-way. So what would you > suggest? I have tried to just have a bean and use the default bean mapper > but I couldn't get it to understand my more complex types (like a case > result to an enum). > > Also, the bean mapper does not look to be super efficient. > > Thanks for any guidance here! > > R. > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
