Hello Sergey, Thanks a lot for this detailed report! Some points are answered already in this mail. I'll have a look at the other ones asap.
> 1. This row can be removed from jooq-trunk\jOOQ\pom.xml (because you've > removed dependency on ojdbc): > oracle.sql;resolution:=optional, Nice catch! Will be removed: https://sourceforge.net/apps/trac/jooq/ticket/1287 Do you know whether these parts of the pom.xml can be generated from the pom.xml itself? > 4. Problem in SequenceFunction.getQualifiedName: it renders invalid sql > query if default schema set. For example: > AbstractQuery.execute; SQL [select ."AU_AUDIT_LOG_SEQ".nextval from dual]; > ORA-00936: missing expression > You can find that query does not contain schema name (because sequence is > located in default schema), but contains separator char '.'. Workaround in > this case is removing default schema setting. Thanks. I'll have a look at this: https://sourceforge.net/apps/trac/jooq/ticket/1288 > 5.DefaultBindContext contains logger for class Util? > private static final JooqLogger log = > JooqLogger.getLogger(Util.class); That's wrong, of course... https://sourceforge.net/apps/trac/jooq/ticket/1289 Cheers Lukas 2012/4/9 Sergey Epik <[email protected]>: > Hello Lukas, > > We've finished our project recently with one of the 2.0.x snapshots (built > from our local branch). > Now we are trying to upgrade to latest jOOQ and found several minor issues. > > 1. This row can be removed from jooq-trunk\jOOQ\pom.xml (because you've > removed dependency on ojdbc): > oracle.sql;resolution:=optional, > > 2. In order to generate classes from xsd we suggest: > > add the following section to jooq-trunk\jOOQ\pom.xml (after > <build><plugins>): > > <plugin> > <groupId>org.jvnet.jaxb2.maven2</groupId> > <artifactId>maven-jaxb2-plugin</artifactId> > <version>0.8.1</version> > <executions> > <execution> > <goals> > <goal>generate</goal> > </goals> > </execution> > </executions> > <configuration> > <extension>true</extension> > <strict>false</strict> > <schemaDirectory>src/main/resources/xsd</schemaDirectory> > <schemaIncludes> > <include>jooq-runtime-2.1.0.xsd</include> > </schemaIncludes> > <generatePackage>org.jooq.conf</generatePackage> > <args> > <arg>-Xxew</arg> > <arg>-Xxew:instantiate lazy</arg> > <arg>-Xxew:delete</arg> > <arg>-Xfluent-api</arg> > <arg>-Xdefault-value</arg> > </args> > <plugins> > <plugin> > <groupId>com.github.jaxb-xew-plugin</groupId> > <artifactId>jaxb-xew-plugin</artifactId> > <version>1.0</version> > </plugin> > <plugin> > <groupId>org.jvnet.jaxb2_commons</groupId> > <artifactId>jaxb2-fluent-api</artifactId> > <version>3.0</version> > </plugin> > <plugin> > <groupId>org.jvnet.jaxb2_commons</groupId> > <artifactId>jaxb2-default-value</artifactId> > <version>1.1</version> > </plugin> > </plugins> > </configuration> > </plugin> > > remove jars from lib, generated classes from package org.jooq.conf (all > classes except org.jooq.conf.SettingsTools), build.xml > > 3. After previous change generated classes (located in > jOOQ\target\generated-sources\xjc) should contain setters for list members. > These setters are important for us. Pay attention that at this moment > generated classes on SVN do not have them. For example, RenderMapping does > not have setter for member schemata. We need these setters to configure > FactoryProxy with settings in spring configuration file, something like > this: > > <bean id="jOOQFactoryProxy" class="org.jooq.util.spring.FactoryProxy"> > <property name="dataSource" ref="transactionAwareDataSource"/> > <property name="settings"> > <bean class="org.jooq.conf.Settings"> > <property name="renderMapping"> > <bean class="org.jooq.conf.RenderMapping"> > <property name="schemata"> > <list> > <bean class="org.jooq.conf.MappedSchema"> > <property name="input" value="AA"/> > <property name="output" > value="${real.aa.db.schema}"/> > </bean> > </list> > </property> > </bean> > </property> > </bean> > </property> > <property name="dialect"> > <value type="org.jooq.SQLDialect">ORACLE</value> > </property> > </bean> > > 4. Problem in SequenceFunction.getQualifiedName: it renders invalid sql > query if default schema set. For example: > AbstractQuery.execute; SQL [select ."AU_AUDIT_LOG_SEQ".nextval from dual]; > ORA-00936: missing expression > You can find that query does not contain schema name (because sequence is > located in default schema), but contains separator char '.'. Workaround in > this case is removing default schema setting. > > 5.DefaultBindContext contains logger for class Util? > private static final JooqLogger log = > JooqLogger.getLogger(Util.class); > > 6. After the latest changes in org.jooq.impl.Function jooq always renders > function with round brackets (Oracle dialect should omit round brackets if > parameter list is empty). For example, we use Oracle function > "CURRENT_TIMESTAMP". In 2.0.x jOOQ rendered it without '()'. Now it adds > round barckets: current_timestamp(). > We haven't found workaround yet, if we specify default value, like here: > Factory.function("current_timestamp", SQLDataType.TIMESTAMP, Factory.val(6) > ) > jOOQ tries to bind integer value "6", but Oracle returns "ORA-30088: > datetime/interval precision is out of range" in this case too. > > > -- > Best regards, > Sergey Epik > > > > > On Fri, Apr 6, 2012 at 12:38 PM, Lukas Eder <[email protected]> wrote: >> >> Hello Sergey, >> >> > Have you had a chance look at the example I sent on 4-Dec? It >> > demonstrates >> > the way how FactoryProxy can be used (src/test dir). >> > Attached you can find last version of FactoryProxy class. >> >> I must've missed that one e-mail, although I starred it in gmail. >> Sorry for that. >> >> Your suggestion looks very solid! As a matter of fact, I'm wondering >> whether I should get some inspiration from it. Your DAO interface and >> implementation could be something that jOOQ-codegen could generate, >> optionally. The POJO's (what you put in the "domain" package) are >> already generated as well. It would only be logical, to provide more >> generated data access abstraction for 80% of the use cases, where >> simple CRUD is sufficient. With your test case, it would be simple to >> run integration tests on generated DAOs before every release. >> >> This would mean: >> >> 1. There is an option to generate DAO interfaces >> 2. There is an option to generate Spring-annotated implementations for >> those interfaces >> 3. There is an option to generate EJB 3.0-annotated implementations >> for those interfaces (I would have to look into that first) >> 4. Some customisation would be useful for additional custom POJOs and DAOs >> >> Optionally, I could start thinking about allowing some user code >> sections in generated classes, that are "kept alive" between >> subsequent generations. >> >> What do you think about these ideas? >> >> > Attached you can find last version of FactoryProxy class. >> > It's pretty simple and we decided include it our project (and not to use >> > jOOQ-spring module). >> > Thank you very much for adding FactoryOperations interface. It makes >> > FactoryProxy possible. >> >> I like this implementation. It looks better than the previous one with >> ThreadLocal variables and many Spring dependencies. Now, there is only >> one dependency, the @Required annotation. Do you think that is really >> needed? The version from december 04 didn't have that dependency. If >> it can be omitted, the FactoryProxy could make it into jOOQ core, and >> I'd maintain it for you... >> >> Cheers >> Lukas >> >> PS: Have you had a chance to look at the latest improvements from jOOQ >> 2.1.0? I remember discussing enum support with you. With the help of >> Christopher Deckers, the jOOQ Console developer, I could establish a >> generic solution to introduce custom types in jOOQ. I'd be curious to >> hear your feedback on that matter. >> >> 2012/4/5 Sergey Epik <[email protected]>: >> > Hello Lukas, >> > >> > Have you had a chance look at the example I sent on 4-Dec? It >> > demonstrates >> > the way how FactoryProxy can be used (src/test dir). >> > Attached you can find last version of FactoryProxy class. >> > It's pretty simple and we decided include it our project (and not to use >> > jOOQ-spring module). >> > Thank you very much for adding FactoryOperations interface. It makes >> > FactoryProxy possible. >> > >> > -- >> > Best regards, >> > Sergey >> > >> > >> > >> > >> > On Sun, Dec 4, 2011 at 8:00 PM, Sergey Epik <[email protected]> >> > wrote: >> >> >> >> Hello Lukas, >> >> >> >> Please find in attacment latest FactoryProxy and simple unit tests, >> >> that >> >> demonstrate usage of jOOQ in spring container. >> >> You can find that FactoryProxy does not depend on Spring at all, it >> >> just >> >> provide thread safe access to factory operations. >> >> Transaction aware data source manages connection (takes it from target >> >> datasource, binds connection to the current thread, closes connection) >> >> , so >> >> it's important that code should be intercepted by transaction manager. >> >> >> >> Test cases are inspired by tests from querydsl-spring integration. >> >> Here is example of usage querydsl-spring: >> >> >> >> >> >> https://github.com/SpringSource/spring-data-jdbc-ext/blob/master/spring-data-jdbc-core/src/test/java/org/springframework/data/jdbc/query/QueryDslCustomerDao.java >> >> I am not sure that integration with JdbcTemplate is a perfect solution. >> >> It >> >> can give some benefits: >> >> - connection is released to the pool after query execution (connection >> >> may >> >> be reused for other tasks) >> >> - mapping SQLException codes to exception hierarchy ( >> >> >> >> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/dao/package-summary.html >> >> ), it's possible to provide custom SQLErrorCodesTransalator. >> >> I think that much better to add this features to jOOQ in the future, >> >> than >> >> integrate jOOQ with low level JdbcTemplate API. >> >> >> >> Fell free to remove jooq-spring or to move it to some "sandbox", as >> >> example. >> >> >> >> -- >> >> Best regards, >> >> Sergey >> >> >> > > >
