Hi Stéphane, Thanks for the details. I understand now. The point of the setDateRange() method is really to be invoked by the user only, whereas Hibernate will populate and serialise the private fields directly, not going through accessor methods.
On a SQL level, this would probably be implemented (or supplemented) using triggers or check options. About the performance cost of additional object introspection, it would be > paid only the first time jooq encounters your target type, right? (I > haven't used jooq 3.x yet) jOOQ has an internal reflection cache that can be turned on on a per-Configuration basis. In that case, yes, object introspection should only be done the first time jOOQ encounters such a target type (per Configuration). Re-creating a new Configuration effectively invalidates that cache. In any case, thanks for your feedback here. I'll add a couple of integration tests (and possible feature enhancements) to make sure that this kind of JPA interoperability works. Cheers, Lukas 2014-09-18 12:20 GMT+02:00 Stéphane Cl <[email protected]>: > Here is a simplified example of a hibernate POJO from a past prototype : > http://pastebin.com/uf3ieG1q > > As you can see, absence of javabean-style setters leaves room for some > row-level logic and can help preventing absurd internal states (to some > extent). I agree with the idea that pure OO orientation with relational > database is a myth, but I believe POJOs can be a little smarter than C-like > structures. > About the performance cost of additional object introspection, it would be > paid only the first time jooq encounters your target type, right? (I > haven't used jooq 3.x yet) > > Best > > Le jeudi 18 septembre 2014 08:34:41 UTC+2, Lukas Eder a écrit : >> >> Hello Stéphane, >> >> Quite possibly, jOOQ's DefaultRecordMapper doesn't behave exactly like >> JPA - we don't have integration tests verifying this. If you're using >> JavaBeans-compliant getters and setters (with @Column annotations), then >> you'll be on the safe side. Of course, you can have all sorts of other >> methods on the target type, which will simply be ignored by the >> DefaultRecordMapper. >> >> There's a pending feature request to populate also non-public member >> fields, including those inherited from a super-type: >> https://github.com/jOOQ/jOOQ/issues/3614 >> >> Obviously, the member discovery algorithm will be slower, once we add >> features in that area. >> >> Combined with a package-private default constructor this offers a nice >>> way to implement row-level logic. As an example, you may prefer using a >>> method such as setInterval(start, end) rather than letting users modify >>> start and end dates individually. >> >> >> Interesting, could you show a concrete example? What do you think could >> be done in jOOQ? >> >> Cheers >> Lukas >> >> 2014-09-17 21:10 GMT+02:00 Stéphane Cl <[email protected]>: >> >>> Hello, >>> From the API documentation of Record.into(Type): >>> http://www.jooq.org/javadoc/3.4.x/org/jooq/Record.html#into-E- >>> >>> If a default constructor is available and any JPA Column annotations >>> are found on the provided type, only those are used: >>> >>> - If type contains public single-argument instance methods annotated >>> with Column, those methods are invoked >>> - If type contains public no-argument instance methods starting with >>> getXXX or isXXX, annotated with Column, then matching public setXXX() >>> instance >>> methods are invoked >>> - If type contains public instance member fields annotated with >>> Column, those members are set >>> >>> >>> From there, is it correct to assume that the target type can't be much >>> more than a typical bag of public getters and setters? >>> >>> Some frameworks such as Hibernate are able to populate non-public member >>> fields. Combined with a package-private default constructor this offers a >>> nice way to implement row-level logic. As an example, you may prefer using >>> a method such as setInterval(start, end) rather than letting users modify >>> start and end dates individually. >>> >>> Kind regards >>> >>> -- >>> 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.
