Samir's use is exactly how I use the generated POJOs. Or does the fact that it is still "attached" bother you?
This bothers me a little but can be worked around. I ran into some complications doing something similar in a previous project. The issue we ran into was some values were lazily loaded and the model was passed into our JSON serializer AFTER the connection was closed causing exceptions. I'm not sure if the same issue would arise here but its nice working with plain POJOs and knowing it won't be an issue. Also as Samir mentioned it can mess with serializers. That doesn't mean jOOQ should be responsible for such conveniences. However, if POJO generation was still supported you could also keep the RecordMapper generation to avoid reflection and do something like this. UserPojo user = getPojo(); create.executeInsert(UserPojo.mapper().map(user)); // Alternate API? create.executeInsert(user, UserPojo::mapper); user = create.selectFrom(Tables.USER).where(Tables.USER.ID.eq(1L)). fetchOne(UserPojo::mapper); RecordMappers could be in new classes instead of the DAO, as static fields / methods to the POJOs, or part of the generated Tables. Just a thought. On Tue, Mar 21, 2017 at 10:01 AM, Samir Faci <[email protected]> wrote: > I think the Record type is a bit too complex for a simple model, which is > why I prefer the Pojo. I think I've tried using a record in the past and > Jackson was serializing more data then was really needed to be returned. > > Also, the swagger introspection seems to puke out on me when I try to use > the record data type. I can look into it a bit more if you'd like, but > mainly I think the object contains state and other attributes that aren't > really necessary when all you want to convey is "Here's some data". > > > > > > On Tue, Mar 21, 2017 at 6:44 AM, Lukas Eder <[email protected]> wrote: > >> Interesting, it makes sense of course. On the other hand, would a Record >> as a model returned by a REST service be sufficient? Or does the fact that >> it is still "attached" bother you? >> >> >> 2017-03-21 14:39 GMT+01:00 Samir Faci <[email protected]>: >> >>> I tend to use the auto-generated POJO for a simple entity. >>> >>> so if I had a table named User for example, I might just use the >>> auto-generated POJO as a Model returned by a REST service and just fetch >>> into it. >>> >>> That's definitely not sufficient when the tables get more complicated, >>> but it's free code I don't have to write. I didn't mean that POJO >>> supported all my use cases, but my use of auto-gen code is usually Records >>> + Pojos, once we get into custom code I can't get away from writing >>> specialized behavior, nor would I expect Jooq to support my internal uses. >>> >>> >>> >>> On Tue, Mar 21, 2017 at 6:33 AM, Lukas Eder <[email protected]> >>> wrote: >>> >>>> Thanks a lot for the feedback, Samir >>>> >>>> 2017-03-21 14:20 GMT+01:00 Samir Faci <[email protected]>: >>>> >>>>> I looked at pulling DAO into our auto-generation code and never really >>>>> found much use to them. Usually the way they fetch a record isn't really >>>>> correct for my use case. >>>>> >>>>> ie. A lot of times fetching by the PKey isn't what I'm looking for >>>>> and at least when I was looking at this there wasn't really an obvious way >>>>> of doing custom fetching behavior or really to expand upon it. >>>>> >>>>> For simple Crud I'd much rather use the Record type. >>>>> >>>>> record.refresh() >>>>> record.update() >>>>> record.store() >>>>> >>>> >>>> That's exactly the point. >>>> >>>> >>>>> give me all I actually care about and the .fetchInto() combined with >>>>> the auto-generated pojos are all I've used. >>>>> >>>> >>>> Oh, interesting bit about the auto-generated POJOs. So, they're >>>> sufficient for (most) of your use-cases? From the jOOQ perspective, they're >>>> closely linked to the DAOs (so, the deprecation *might* also touch on that >>>> POJO generation). >>>> >>>> >>>>> +1 on dropping support for it. I don't object to DAO/Repository >>>>> design pattern but I find that I usually need to write customized >>>>> code rather then relying on auto-generated code for most of my use >>>>> cases. >>>>> >>>> >>>> Exactly. The DAOs are too opinionated / simple for that customized >>>> implementation >>>> >>>> -- >>>> 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. >>>> >>> >>> >>> >>> -- >>> Thank you >>> Samir Faci >>> https://keybase.io/csgeek >>> >>> -- >>> 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. >> > > > > -- > Thank you > Samir Faci > https://keybase.io/csgeek > > -- > You received this message because you are subscribed to a topic in the > Google Groups "jOOQ User Group" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/jooq-user/-LnkZtUTb3c/unsubscribe. > To unsubscribe from this group and all its topics, 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.
