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() give me all I actually care about and the .fetchInto() combined with the auto-generated pojos are all I've used. +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. -- Samir Faci On Mon, Mar 20, 2017 at 9:47 AM, Lukas Eder <[email protected]> wrote: > Dear group, > > The DAO type has been haunting this list ever since it was added to the > library in version 2.4 (2012). At the time, it was a quick win over a > competing library that already had the feature. They were extremely easy to > implement in jOOQ. > > However, DAOs (much like repositories, e.g. in Spring Data) are some of > the most opinionated things in software. As such, they require either: > > - A very strong opinion on the matter (duh), but jOOQ doesn't have one > - An extremely versatile design that satisfies all needs, which is > probably not possible > > This list has debated DAOs time and again in the past. There had been many > feature requests, extension requests, and people criticising jOOQ's use of > the Java final keyword as it prevents the application of the open-closed > principle, at least in those people's understanding. My understanding is a > bit different: https://blog.jooq.org/2017/03/20/the-open-closed-principle- > is-often-not-what-you-think-it-is > > In fact, people bumping into jOOQ's usage of final in this area simply > shows that the design (or the vision) is insufficient in this particular > case. Otherwise, there would be no desire to "hack" additional behaviour > into the existing API through what I believe to be a highly overrated tool > of object orientation: Concrete class overriding. > > Non-essential, yet incomplete features distract us from what jOOQ really > does well: SQL language abstraction. And this causes great harm to the > library as I'd really rather be implementing features like MULTISET, > SQL's temporal validity, better XML and JSON support, etc. etc. than > debating DAOs. > > *I am thus proposing the deprecation of the DAO type per jOOQ 3.10, and > its removal per jOOQ 4.0:* > *https://github.com/jOOQ/jOOQ/issues/5984 > <https://github.com/jOOQ/jOOQ/issues/5984>* > > I would like to invite you to join this discussion either to: > > - Confirm that you agree with this move > - Request we continue supporting DAOs (in case of which: please illustrate > why they're a killer feature for you) > > Best Regards, > Lukas > > -- > 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.
