Hi Leigh, Thanks for your feedback. I guess you can upvote this feature request, then: https://github.com/jOOQ/jOOQ/issues/2520
:) Indeed, that should be possible in a (hopefully near) future version. Specifically, the DefaultRecordMapper logic should be made available in reverse form through a new "DefaultRecordUnmapper" Do note that some logic is already available through Record.from(Object). Best Regards, Lukas 2016-07-08 3:12 GMT+02:00 Leigh Whiting <[email protected]>: > My question is similar (and perhaps is covered already) but goes in a > slightly different direction. > > I really like the JOOQ record mapper implementation for fetching > "auto-magically" straight into custom POJOs - we tend to use this a bit > when our domain classes don't nicely reflect what can be stored easily in a > database. > > However, it would be great if the inverse operation was also pluggable: > mapping a POJO into a record (via a record mapper or similar interface). > For every instance a record mapper is used in our source we have code (not > plugged into JOOQ) that performs the conversion the other way (POJO -> > Record via a mapper). It would be great if JOOQ could support record > mappers that knew how to convert both ways. > > Cheers, > Leigh > > On Thursday, July 7, 2016 at 6:35:38 PM UTC+10, Lukas Eder wrote: >> >> Hi Samir, >> >> 2016-07-07 4:50 GMT+02:00 Samir Faci <[email protected]>: >> >>> 1. One conversion that would be useful to have is the ability to >>> convert from POJOs to Records and vice versa. >>> >>> On occasion I need to roll out my own POJO because our data is >>> represented different at the service layer then how the data >>> is actually stored, but I find myself using the autogenerated records >>> and POJOs a good bit. It would be nice if there was an easy way to going >>> from say: >>> >>> TableNameRecord --> TableName (pojo) and back. >>> >> >> Do I get you right, you'd like a hard-coded method in the generated >> TableNameRecord that does the mapping for the generated POJO? E.g. >> >> >> class TableNameRecord extends UpdatableRecordImpl { >> ... >> public TableNamePojo intoTableNamePojo() { ... } >> public void fromTableNamePojo(TableNamePojo pojo) { ... } >> } >> >> >> Would this really help? I can definitely see the into() method. The >> from() method doesn't seem to add that much value over the existing >> Record.from(Object) method, except, perhaps, some additional type safety? >> >> >>> It varies on my use case but I tend to usually fetchInto( . class) and >>> most of the the class passed in is either the record or pojo that was >>> generated by jooq. >>> >> >> Oh, I see, that's a different story, though. The problem is that >> fetchInto(Class) is called on a ResultQuery<R>, where R is a generic type. >> It will be a bit harder to find a solution along the lines of what you're >> looking for. Perhaps, we could generate a RecordMapper<TableNameRecord, >> TableNamePojo>, which would add some type safety over passing the class >> literal (and it could be implemented more optimally). That RecordMapper >> could then be made available from TableNameRecord: >> >> class TableNameRecord extends UpdatableRecordImpl { >> ... >> >> public static RecordMapper<TableNameRecord, TableNamePojo> mapper() { >> ... } >> >> } >> >> >> This could then be used as such: >> >> dsl.select(...).from(...).fetchInto(TableNameRecord.mapper()) >> >> >> What do you think? >> > -- > 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.
