Re: addBatch support and multiple autogenerated keys
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 : > Hi Lukas, > My comments inline > > On Wed, Oct 26, 2011 at 4:18 PM, Lukas Eder 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
Re: addBatch support and multiple autogenerated keys
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. 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. > 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. > 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 Cheers Lukas
Re: addBatch support and multiple autogenerated keys
Hi Lukas, Thanks for the update. We have integrated jooq as the lib for adhoc queries in the framework. We haven't really used the add batch support in jooq for now as we generated the code that talks directly with the underlying connection lib. As part of the integration process, we had to make some minor modifications to the jooq code . We have those changes checked in a private github repository for now. We would have a consolidated list of changes once we have finished with our framework and also released our service. We would by then also have a good understanding of jooq code. 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. Most of the changes were related to making some "impl" classes public to allow for use/(and extension) outside the org.jooq.impl package . And other notable ones are - We have split the TableRecord interface into TableRecord and LiveTableRecord (forget the naming). LiveTableRecord contains the db ops. - Support for "JoinProvider" (again forget the naming) interface in join methods in order to support adding of both table and the join conditions. - Extension to the configuration that allows for closing connections after the query execution. thanks and regards, -kps- On Wed, Oct 26, 2011 at 1:46 AM, Lukas Eder wrote: > Hello, > > Please note that I have added JDBC batch operation support on trunk. > Find the full discussion here: > https://groups.google.com/forum/#!topic/jooq-user/o52n5u3XDTk > > Cheers > Lukas > > 2011/9/13 Saravanan KP : > > Hi lukas, > > Thanks a lot for the feature. > > As I am currently working on the framework I had mentioned earlier , > > I will not be able to test it immediately. Will let you know by this > > week end. > > > > regards, > > -kps- > > > > > > > > On Sep 12, 11:29 pm, Lukas Eder wrote: > >> Hello, > >> > >> > Mysql Auto Increment > >> > -- > >> > I would like to insert a set of records on a table containing > >> > autogenerated keys. Is there any way of getting multiple autogenerated > >> > keys when using > >> > insert into t values(..).values(..). > >> > >> Fetching several ID values from multi-record insert statements is now > >> supported with jOOQ 1.6.6. The DSL syntax to achieve this behaviour is > >> this: > >> > >> Result result = create > >> .insertInto(MY_TABLE, MyTable.COL1, MyTable.COL2) > >> .values(1, "a") > >> .values(2, "b") > >> .values(3, "c") > >> .returning(MyTable.ID) > >> .fetch(); > >> > >> This currently works for DB2, HSQLDB, MySQL, and Postgres. Other JDBC > >> drivers don't seem to fully support selecting several generated keys. > >> See the manual for more info about INSERT support in jOOQ: > >> > >> https://sourceforge.net/apps/trac/jooq/wiki/Manual/JOOQ/Query > > >
Re: addBatch support and multiple autogenerated keys
Hello, Please note that I have added JDBC batch operation support on trunk. Find the full discussion here: https://groups.google.com/forum/#!topic/jooq-user/o52n5u3XDTk Cheers Lukas 2011/9/13 Saravanan KP : > Hi lukas, > Thanks a lot for the feature. > As I am currently working on the framework I had mentioned earlier , > I will not be able to test it immediately. Will let you know by this > week end. > > regards, > -kps- > > > > On Sep 12, 11:29 pm, Lukas Eder wrote: >> Hello, >> >> > Mysql Auto Increment >> > -- >> > I would like to insert a set of records on a table containing >> > autogenerated keys. Is there any way of getting multiple autogenerated >> > keys when using >> > insert into t values(..).values(..). >> >> Fetching several ID values from multi-record insert statements is now >> supported with jOOQ 1.6.6. The DSL syntax to achieve this behaviour is >> this: >> >> Result result = create >> .insertInto(MY_TABLE, MyTable.COL1, MyTable.COL2) >> .values(1, "a") >> .values(2, "b") >> .values(3, "c") >> .returning(MyTable.ID) >> .fetch(); >> >> This currently works for DB2, HSQLDB, MySQL, and Postgres. Other JDBC >> drivers don't seem to fully support selecting several generated keys. >> See the manual for more info about INSERT support in jOOQ: >> >> https://sourceforge.net/apps/trac/jooq/wiki/Manual/JOOQ/Query >
Re: addBatch support and multiple autogenerated keys
Hi lukas, Thanks a lot for the feature. As I am currently working on the framework I had mentioned earlier , I will not be able to test it immediately. Will let you know by this week end. regards, -kps- On Sep 12, 11:29 pm, Lukas Eder wrote: > Hello, > > > Mysql Auto Increment > > -- > > I would like to insert a set of records on a table containing > > autogenerated keys. Is there any way of getting multiple autogenerated > > keys when using > > insert into t values(..).values(..). > > Fetching several ID values from multi-record insert statements is now > supported with jOOQ 1.6.6. The DSL syntax to achieve this behaviour is > this: > > Result result = create > .insertInto(MY_TABLE, MyTable.COL1, MyTable.COL2) > .values(1, "a") > .values(2, "b") > .values(3, "c") > .returning(MyTable.ID) > .fetch(); > > This currently works for DB2, HSQLDB, MySQL, and Postgres. Other JDBC > drivers don't seem to fully support selecting several generated keys. > See the manual for more info about INSERT support in jOOQ: > > https://sourceforge.net/apps/trac/jooq/wiki/Manual/JOOQ/Query
Re: addBatch support and multiple autogenerated keys
Hello, > Mysql Auto Increment > -- > I would like to insert a set of records on a table containing > autogenerated keys. Is there any way of getting multiple autogenerated > keys when using > insert into t values(..).values(..). Fetching several ID values from multi-record insert statements is now supported with jOOQ 1.6.6. The DSL syntax to achieve this behaviour is this: Result result = create .insertInto(MY_TABLE, MyTable.COL1, MyTable.COL2) .values(1, "a") .values(2, "b") .values(3, "c") .returning(MyTable.ID) .fetch(); This currently works for DB2, HSQLDB, MySQL, and Postgres. Other JDBC drivers don't seem to fully support selecting several generated keys. See the manual for more info about INSERT support in jOOQ: https://sourceforge.net/apps/trac/jooq/wiki/Manual/JOOQ/Query
Re: addBatch support and multiple autogenerated keys
Hello, > AddBatch > -- > Is addBatch supported? I searched in the code and > couldn't find any reference. > http://download.oracle.com/javase/1.4.2/docs/api/java/sql/PreparedStatement.html#addBatch() Currently, this is not supported. I have an open ticket for this in Trac, but I'm not sure how this could be supported conveniently by the API: https://sourceforge.net/apps/trac/jooq/ticket/621 I'm open to suggestions > Mysql Auto Increment > -- > I would like to insert a set of records on a table containing > autogenerated keys. Is there any way of getting multiple autogenerated > keys when using > insert into t values(..).values(..). > > lastID() method returns only one. > > The InsertQueryImpl does seem to use getGeneratedKeys in two > places.But in both , only one id seems to be fetched. Yes, this is a flaw of the initial implementation for the Postgres INSERT .. RETURNING clause. I realised only later, that most RDBMS actually support returning several records from an INSERT statement. This will be fixed in 1.6.6: https://sourceforge.net/apps/trac/jooq/ticket/826 With jOOQ 1.6.5, you can only insert one record at a time, if you want to fetch generated keys. Cheers Lukas
