Hi Bill 2017-03-20 23:06 GMT+01:00 Bill O'Neil <[email protected]>: > > 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. >
Hmm, that link clearly indicates the problem here. The documentation is not good enough. I've added this point to the relevant issue: https://github.com/jOOQ/jOOQ/issues/5816 And then, there will be some features that DAO can currently do and that don't have a corresponding method in DSLContext. That will be fixed along with the deprecation. > 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. > OK, thanks for your explanations, that's very interesting. Your approach does seem to work fine for you, you've found a pragmatic balance between what works "for now", and how things should be done once models become more complex. I think this is what many experienced users of a framework will eventually do. My goal here is to make it very easy and obvious for new users as well. The DAO "case" is a quite orthogonal way of doing things in jOOQ. Sure, it works for some needs, but I'd like jOOQ to be an API that *always* works in all cases. A user shouldn't have the cognitive overhead of thinking: "How do I best use jOOQ *in this case*". Which again means: All the useful stuff in DAO should be moved to DSLContext where it fits the query model without being distracted by this 1:1 model mapping "philosophy". 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 see. No, what's published on GitHub and Maven Central is purely ASL 2.0 licensed, so there's absolutely no problem for anyone to fork that. Of course, I'd prefer to find a solution that makes a fork unnecessary, because the solution should be much better than any fork could be. > I will need to look through some more blog posts and see if I have fallen > into the DAO rabbit hole :). > I don't think you have. You've found a pragmatic solution, which is fine. -- 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.
