I use the DAOs quite heavily on my side projects and find them to be very helpful for simple CRUD operations which I believe was the intention.
However, I also think it would be doing a disservice to the jOOQ community if you are wasting lot's of time on feature requests and answering questions on DAOs. Do you find it a burden to keep DAO generation up to date with newer versions of jOOQ? If not, I would ask if you could split it to its own release schedule and freeze all features. In this case you just list breaking changes (github issues?) and ask the community to contribute. Once all changes are made you can review and release. Freezing features still gives simple crud but all new features should be rejected. If someone wants additional functionality they can fork or write custom generators. You would still need to work on it occasionally but hopefully drastically less and it wouldn't block the release schedule of more important features. If yes, possibly find someone else to take it over, someone who says no to most feature requests preferably ;)? My killer features - Simplicity, You get CRUD for free out of the box. - Optimizations such as SQL batching under the hood for free. - POJO generation - I just let a lot of these classes pass through my whole codebase since they are plain POJOs. If I need something special or some optimization then I can map them to other POJOs later. When I need to add functionality I just have a class that uses composition with one or more DAOs. Sure there is some boilerplate and it might just pass through to the DAO for a lot of methods but it takes almost no effort to do that. The more complex queries then use the DSL directly. I'm not sure if this could have any dual licensing issues. Bill On Monday, March 20, 2017 at 12:47:07 PM UTC-4, Lukas Eder 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.
