Late but still interesting... https://github.com/jOOQ/jOOQ/issues/2797 has been fixed for jOOQ 3.6. See also:
- https://github.com/jOOQ/jOOQ/issues/3614 - https://github.com/jOOQ/jOOQ/issues/3643 Also, caching of reflection information has been implemented some releases ago Cheers, Lukas Am Dienstag, 22. Oktober 2013 18:02:10 UTC+2 schrieb Darren S: > > I think this will work perfectly for what I need. I'm finding I need to > do more mapping logic, so writing my own custom RecordMapper seems fine. > Two things struck me as odd with the implemention of the > DefaultRecordMapper. 1) Because it does Class.getFields(), it will only > map public fields. So most @Column annotations on class fields are usually > protected. 2) None of the reflection logic is cached. So if I have a class > with ten fields it seems that every call to fetchInto (or really any new > DefaultRecordMapper), will do n^2 loops looking for matches. Maybe caching > is unnecessary. I haven't really profiled the code yet to see the overhead > of jOOQ. > > Darren > > On Friday, October 11, 2013 2:32:32 AM UTC-7, Lukas Eder wrote: >> >> Hi Darren, >> >> jOOQ's fetchInto(Class) method uses jOOQ's internal DefaultRecordMapper: >> http://www.jooq.org/javadoc/latest/org/jooq/impl/DefaultRecordMapper.html >> >> You can override this by supplying your Configuration with a custom >> RecordMapperProvider: >> >> http://www.jooq.org/doc/3.2/manual/sql-execution/fetching/pojos-with-recordmapper-provider/ >> >> This allows you to hook a global RecordMapper into jOOQ, which takes care >> of the instantiation. If you still want to use the DefaultRecordMapper and >> its JPA annotation parsing capabilities on your custom instance, then you >> might try your luck with Record.into(E), which does precisely that: >> http://www.jooq.org/javadoc/latest/org/jooq/Record.html#into(E) >> >> Hope this helps, >> Lukas >> >> 2013/10/10 <[email protected]> >> >>> First off let me say how impressed I am with jooq, great job! >>> >>> I'm trying to migrate from a custom data access library to jooq. The >>> current implementation uses VO/DTOs that are annotated with JPA >>> annotations. The fetchInto() works great. Now I can't completely ditch >>> the old framework but need to make jooq work side by side. The problem I >>> have is that the JPA annotated DTOs are current enhanced by cglib and cglib >>> interceptors track changes to the DTO. So if I want to query with jooq and >>> persist with the custom framework I need to be able to have jooq >>> fetchInto() a custom cglib enhanced object. >>> >>> In jooq 3.1 (just noticed 3.2 today) there is only fetchInto(class). >>> Ideally I would like fetchInto(class, obj) or some ability to register a >>> custom object instantiator. I think the first option would be more >>> flexible as the obj passed in can be created based on contextual >>> information. Basically I want to instantiate the object and do >>> manipulations to it and then tell jooq read metadata from the class but set >>> fields on the obj I constructed. >>> >>> Does that make sense? I'd be willing to even do the enhancement myself >>> if this seems okay. Some general pointer on what to change would be good. >>> Or maybe jooq can already do this in a different way or now in 3.2. >>> >>> Thanks, >>> Darren >>> >>> -- >>> 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/groups/opt_out. >>> >> >> -- 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.
