Hi Darren 2013/10/22 <[email protected]>
> 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. > Great! > 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. > True, that is not entirely correct, according to the JPA specification. I'll have to review that spec https://github.com/jOOQ/jOOQ/issues/2797 However, I prefer not to change too many things in that default implementation, as many users might rely on the current behaviour. Maybe a more JPA-compliant implementation should be made, which will have to be applied explicitly > 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. > The reflection logic is cached within a DefaultRecordMapper, which in turn is not cached by default. Caching had been discussed in this thread: https://groups.google.com/forum/#!searchin/jooq-user/caching$20reflection/jooq-user/mM19mjR-49g/QOHi2XShZcYJ As implementing a correct cache is non-trivial (e.g. how to interact with OSGi ClassLoaders?), RecordMapperProvider was added to jOOQ, where you can implement your own caching strategy, even when using the DefaultRecordMapper. I'm willing to re-iterate that other discussion about caching, if you have a good idea. Cheers Lukas > > 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<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/<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)<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 jooq-user+...@**googlegroups.com. >>> >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<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/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/groups/opt_out.
