If a constructor doesn't have a ConstructorProperties annotation, we'll simply map all values from the record onto the constructor in the order of appearance, regardless of their names. The current contract of DefaultRecordMapper is this: If no default constructor is available, but at least one constructor annotated with ConstructorProperties is available, that one is used
- The standard JavaBeans ConstructorProperties <http://java.sun.com/javase/6/docs/api/java/beans/ConstructorProperties.html?is-external=true> annotation is used to match constructor arguments against POJO members or getters. - If those POJO members or getters have JPA annotations, those will be used according to the aforementioned rules, in order to map Record values onto constructor arguments. - If those POJO members or getters don't have JPA annotations, the aforementioned naming conventions will be used, in order to map Record values onto constructor arguments. - When several annotated constructors are found, the first one is chosen (as reported by Class.getDeclaredConstructors() <http://java.sun.com/javase/6/docs/api/java/lang/Class.html?is-external=true#getDeclaredConstructors--> - When invoking the annotated constructor, values are converted onto constructor argument types If no default constructor is available, but at least one "matching" constructor is available, that one is used - A "matching" constructor is one with exactly as many arguments as this record holds fields - When several "matching" constructors are found, the first one is chosen (as reported by Class.getDeclaredConstructors() <http://java.sun.com/javase/6/docs/api/java/lang/Class.html?is-external=true#getDeclaredConstructors--> - When invoking the "matching" constructor, values are converted onto constructor argument types See also: http://www.jooq.org/javadoc/latest/org/jooq/impl/DefaultRecordMapper.html Since @ConstructorProperties is about telling reflection tools what constructor argument maps to what JavaBeans property, It will certainly make sense to extend jOOQ's current behaviour in order to ignore the fact whether a getter is present or not. jOOQ's understanding of how to map an org.jooq.Field onto a class "property" is already established. 2015-01-09 17:57 GMT+01:00 Robert DiFalco <[email protected]>: > Yeah, it's a tough call. What about a constructor without a > ConstructorProperties annotation. Would it have the same issue in JOOQ that > if a getter existed for only some of the ctor args it would erase those > that didn't? > > On Friday, January 9, 2015 at 2:16:36 AM UTC-8, Lukas Eder wrote: >> >> ... Hmm, or perhaps not a bug. Check out the Javadoc of >> ConstructorProperties: >> http://docs.oracle.com/javase/8/docs/api/java/beans/ >> ConstructorProperties.html >> >> An annotation on a constructor that shows how the parameters of that >> constructor correspond to the constructed object's getter methods. For >> example: >> >> public class Point { >> @ConstructorProperties({"x", "y"}) >> public Point(int x, int y) { >> this.x = x; >> this.y = y; >> } >> >> public int getX() { >> return x; >> } >> >> public int getY() { >> return y; >> } >> >> private final int x, y; >> } >> >> The annotation shows that the first parameter of the constructor can be >> retrieved with the getX() method and the second with the getY() method. >> Since parameter names are not in general available at runtime, without the >> annotation there would be no way to know whether the parameters correspond >> to getX() and getY() or the other way around. >> >> Clearly, the intent of this annotation is to document a correlation >> between constructor arguments and properties that *do have* getters. >> >> I still agree that from a usability perspective, jOOQ shouldn't care too >> much about the presence of such getters, but it's interesting to know the >> contract of the actual annotation. >> >> Cheers >> Lukas >> >> >> 2015-01-09 8:10 GMT+01:00 Lukas Eder <[email protected]>: >> >>> Thanks for reporting. This is a bug: >>> https://github.com/jOOQ/jOOQ/issues/3911 >>> >>> Best Regards, >>> Lukas >>> >>> 2015-01-08 23:50 GMT+01:00 Robert DiFalco <[email protected]>: >>> >>>> I'm having a problem with Immutable POJOs. Well, not Immutable but with >>>> a constructor annotated with @ConstuctorProperties. As I'm typing this I'm >>>> wonder if getters can overwrite constructor names. But here's the issue I'm >>>> having: >>>> >>>> I have a query returning one Numeric identity field and three Timestamp >>>> fields. I have a POJO with a constructor like this: >>>> >>>> @ConstructorProperties({"id", "lastCalled", "lastAnswered", >>>> "lastConnected"}) >>>> public FriendCallInfo(final Long id, final Timestamp lastCalled, >>>> final Timestamp lastAnswered, final Timestamp lastConnected) {...} >>>> >>>> But this constructor only ever gets called with "id". What's >>>> interesting is that I only have one getter on this class and it is for >>>> #getId. The others don't have proper getters. That makes me wonder if the >>>> JOOQ implementation is trying to be clever, so instead of just using my >>>> ConstructorProperties it is also looking for fields and getters. Since it >>>> finds one for #getId it ignores the other properties in my Constructor. >>>> >>>> Yes it looks like that is the case. If I rename #getId to something >>>> like #getThisId then even the ID doesn't get sent to the constructor. It >>>> appears as if the contract requires not only a properly annotated >>>> constructor but also either a field or member with the same name as the >>>> constructor property. >>>> >>>> Would you consider this a bug and if so should I create an issue for >>>> it? It seems like I should be able to create a java object that has a well >>>> defined constructor that may take a different form than the getters and >>>> setters of the bean. I currently do it this way in JPA. But maybe that >>>> breaks some contract. >>>> >>>> Thanks! >>>> >>>> -- >>>> 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. > -- 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.
