Hello, >> That is unlikely to make it into the core. jOOQ aims for clean >> separation of API and implementation. > > We accept that completely. We have a dsl configuration from where the > ddl, dml and jooq code are generated. In some cases we had to override > certain classes. Not at the "App" level but rather at the framework level. > As I had mentioned earlier , we plan to revisit them to ask for your > suggestions once our framework has stabilized. The dsl is not just for > db. It is also reused for client and non "db" operations.
I understand. Looking forward to seeing that. >> If I understand you correctly, this means separation of the "POJO" and >> operations upon the POJO? That's a good idea. > > Yes . We prefer pojos to be just simple objects. It is just our taste . But > that is the whole point of DSL and open source :-) > TableRecord was passed/used in other interfaces so we figured that it would > be lot less change to just split that interface. There is a high chance of such a thing making it into the core in release 2.0, which might just make it in late 2011, depending on the amount of Christmas effort, this year (cookies, etc...) :). I have a couple of ideas too for jOOQ 2.0, which go into the same direction: http://sourceforge.net/apps/trac/jooq/ticket/117 http://sourceforge.net/apps/trac/jooq/ticket/157 > We have the information about the fk. Similar to tables and columns , we > generate that information as a "named configuration object" which could be > reused in joins like > leftJoin(qtable1_using_qtable2) I see, that's nice. I had thought about that too, some time ago: http://sourceforge.net/apps/trac/jooq/ticket/578 jOOQ generates all foreign keys in a Keys class. This information could be quite valuable. > (And yes we have used some of the ideas from querydsl. Like instance instead > of static). I'm still thinking about that. I still believe that when aliasing is not involved, static can be better... Have you modified jOOQ in order to make instance fields in generated code? What experience did you make? > Not the traditional J2EE container. We don't believe that snake oil. Just > a simple connection pool library. OK > Infact we prefered jooq (when compared with querydsl) because the dsl was > more closer to sql and concentration was more on trying to support the db > specific dialects rather than hibernate, jpa integrations. > We really want it to be as close to typing sql as that is the way we > develop. We try out the complex queries directly on the mysql client. Then > convert it into code. The ibatis way is okay but we lose out on compilation > , autocomplete and drill down features that the IDEs provide. Sounds like a success story, right there! I'm glad I found the right solution for some users with exactly that mindset. Regards, Lukas 2011/10/26 Saravanan KP <[email protected]>: > Hi Lukas, > My comments inline > > On Wed, Oct 26, 2011 at 4:18 PM, Lukas Eder <[email protected]> wrote: >> >> Hello, >> >> > We could then discuss on >> > >> > Changes that are acceptable by the jooq community to be added to the >> > core. >> > Changes that were done due to our wrong understanding. >> > And ones that we have to maintain separately. >> >> I'll be very curious to see your improvements! Thanks in advance for >> sharing those. >> >> > Most of the changes were related to making some "impl" classes public to >> > allow for use/(and extension) outside the org.jooq.impl package . >> >> That is unlikely to make it into the core. jOOQ aims for clean >> separation of API and implementation. > > We accept that completely. We have a dsl configuration from where the > ddl, dml and jooq code are generated. In some cases we had to override > certain classes. Not at the "App" level but rather at the framework level. > As I had mentioned earlier , we plan to revisit them to ask for your > suggestions once our framework has stabilized. The dsl is not just for > db. It is also reused for client and non "db" operations. > >> >> That's why most impl classes are >> package private. In the past, I have heavily refactored those classes >> in a way that would have broken any dependencies on them. But if I >> understand your requirements, we can maybe find another way (e.g. like >> the existing CustomField and CustomCondition) >> >> > And other notable ones are >> > We have split the TableRecord interface into TableRecord and >> > LiveTableRecord (forget the naming). LiveTableRecord contains the db >> > ops. >> >> If I understand you correctly, this means separation of the "POJO" and >> operations upon the POJO? That's a good idea. > > Yes . We prefer pojos to be just simple objects. It is just our taste . But > that is the whole point of DSL and open source :-) > TableRecord was passed/used in other interfaces so we figured that it would > be lot less change to just split that interface. > >> >> > Support for "JoinProvider" (again forget the naming) interface in >> > join >> > methods in order to support adding of both table and the join >> > conditions. >> >> That, you'll have to show me. I'm not sure what this is about. > > We have the information about the fk. Similar to tables and columns , we > generate that information as a "named configuration object" which could be > reused in joins like > leftJoin(qtable1_using_qtable2) > (And yes we have used some of the ideas from querydsl. Like instance instead > of static). > >> >> > Extension to the configuration that allows for closing connections after >> > the >> > query execution. >> >> I imagine this is useful in a J2EE container, in order to "close" (or >> return) the connection to the container? Might be worth thinking about >> as a runtime-configuration, once that is added to jOOQ >> > > Not the traditional J2EE container. We don't believe that snake oil. Just > a simple connection pool library. > Infact we prefered jooq (when compared with querydsl) because the dsl was > more closer to sql and concentration was more on trying to support the db > specific dialects rather than hibernate, jpa integrations. > We really want it to be as close to typing sql as that is the way we > develop. We try out the complex queries directly on the mysql client. Then > convert it into code. The ibatis way is okay but we lose out on compilation > , autocomplete and drill down features that the IDEs provide. > >> >> Cheers >> Lukas > > > > thanks and regards, > -kps- >
