> > That's one way of looking at it, but I also think that having these DAOs > is a disservice to the community because the community's time is wasted > trying to figure out how to best use these things (and then after some > time, probably abandon the idea). > You are probably right here I have been using DAOs for 3-4 years now thinking it was the right way to do the CRUD parts. I'd love if you can point me to some of the DSL methods you are referring to. Just took a quick look here https://www.jooq.org/doc/2.6/manual/sql-execution/crud-with-updatablerecords/simple-crud/ I guess I could just then map it to a POJO similar to how the DAOs do it unless there is an easier way.
Absolutely, but that isn't restricted to DAO. During this deprecation, > we'll certainly look at improving (and probably better documenting) the > existing CRUD API in DSLContext > This would probably meet all my needs. Good point, I think that functionality isn't really available as > transparently in DSLContext yet. It is more of a conscious choice, e.g. > through: DSLContext.batchInsert(UpdatableRecord...) This is fine. I generally know when I want to batch and if I switch from DAOs to DSLContext it will seem natural. I would like to learn more about this part - it is the most controversial > aspect of the DAO, because the generated POJOs are really closely coupled > to the existing DAOs, conceptually. Has the rigid 1:1 mapping between > "domain model" and relational model never really bothered you? > Not really, my side projects are small and simple for the most part. I use DAOs when the domain model and relational model map 1:1. If they don't I either use the DSL or sometimes run multiple queries using DAOs. If I have a User model that is backed by a user table and roles table I can fetch from both tables in parallel and join in memory. Sometimes if I know one of the tables has data that infrequently changes I just cache the whole data set in memory and join on that. So, you use DAOs as a pragmatic "starter" or "base implementation" until > they stop working for you? > Pretty much. It sounds like I can achieve the same thing easily with the DSL I will look into this more. I'm not sure if this could have any dual licensing issues. > I wasn't sure if any of the suggestions would cause issues with your licensing model. I don't think it would. I will need to look through some more blog posts and see if I have fallen into the DAO rabbit hole :). On Monday, March 20, 2017 at 5:14:21 PM UTC-4, Lukas Eder wrote: > > Thank you very much for your feedback, Bill. I will comment inline > > 2017-03-20 18:24 GMT+01:00 Bill O'Neil <[email protected] <javascript:>>: > >> 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. >> > > That was absolutely the intention. However, few people know that a lot of > functionality offered by DAOs is also available from DSLContext with almost > the same ease of use. This deprecation is not about the quick-and-dirty > fetch of rows. There's always room for adding more convenience API that > removes some CRUD boilerplate. > > This is about the DAO type (and its code generation), which enforces an > opinionated 1:1 mapping between the domain model and the relational model, > which works only for small projects, or at the beginning, leaving many open > questions later on. > > >> 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. >> > > That's one way of looking at it, but I also think that having these DAOs > is a disservice to the community because the community's time is wasted > trying to figure out how to best use these things (and then after some > time, probably abandon the idea). > > >> Do you find it a burden to keep DAO generation up to date with newer >> versions of jOOQ? >> > > No, that's not a problem at all. It's actually rather trivial, the way it > is now. > > >> 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 ;)? >> > > If this is to be deprecated, then it will be frozen for the jOOQ 3.x > release stream and removed from 4.0. I think it is not a good idea to keep > such things around in a frozen state. > > Note that jOOQ 4.0 is probably still quite some time away. The cost / > benefit ratio of the 4.0 roadmap is not strong enough yet to start > implementing breaking changes. (The most important driver being a > completely immutable DSL). > > Having said so, the existing DAO / DAOImpl APIs and implementations are so > trivial, really, that it will be very easy to fork this functionality to a > new repository if someone will see the need after jOOQ 4.0. > > So, I don't think we'll have an issue here. > > >> My killer features >> - Simplicity, You get CRUD for free out of the box. >> > > Absolutely, but that isn't restricted to DAO. During this deprecation, > we'll certainly look at improving (and probably better documenting) the > existing CRUD API in DSLContext > > >> - Optimizations such as SQL batching under the hood for free. >> > > Good point, I think that functionality isn't really available as > transparently in DSLContext yet. It is more of a conscious choice, e.g. > through: DSLContext.batchInsert(UpdatableRecord...) > > >> - 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. >> > > I would like to learn more about this part - it is the most controversial > aspect of the DAO, because the generated POJOs are really closely coupled > to the existing DAOs, conceptually. Has the rigid 1:1 mapping between > "domain model" and relational model never really bothered you? > > 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. >> > > So, you use DAOs as a pragmatic "starter" or "base implementation" until > they stop working for you? > > >> I'm not sure if this could have any dual licensing issues. >> > > What do you mean by this? > > Thanks again for your feedback, this is very helpful! > -- 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.
