Hello Eric, > Small feature suggestion: > Right now fetchInto seems to require classes with a no-argument > constructor and setters. It would be nice if it could work with > immutable classes, and use constructor arguments (these are > introspectable) instead of setters.
That is a nice idea. I filed this as #1336: https://sourceforge.net/apps/trac/jooq/ticket/1336 Also, there should be an option in jooq-codegen to generate immutable POJOs. This might be useful to some users: https://sourceforge.net/apps/trac/jooq/ticket/1339 Chances are high that this will make it in the next release. We'll have to think about a constructor matching algorithm, though. There is no formal connection between the query being executed and the receiving type of the various .into(Class<?>) methods. When jOOQ can use public instance fields, or setters, the matching algorithm can be more lenient. So I'm guessing that the optimal algorithm would be: 1. If public non-final instance fields are available on the target type, use the default constructor (calling Constructor.setAccessible(true) if necessary) and set fields directly 2. If setters are available, then use the default constructors and set values using setters 3. If a "matching" constructor is available, use that one, passing values to that constructor. By "matching", I mean that the number of fields in record = number of constructor arguments. If types don't match, jOOQ applies type conversion as good as possible (e.g. int => Integer, int => long, int => Number, etc.) 4. If several matching constructors are available, take the first one. The above algorithm can be applied regardless if JPA annotations are available on the target type. Unfortunately, constructor arguments cannot be annotated with javax.persistence.Column, though. Any feedback on this algorithm welcome! Cheers Lukas
