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]>:
> 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.
