Hello Sergey, Some more feedback to your questions:
> 2. In order to generate classes from xsd we suggest: > > add the following section to jooq-trunk\jOOQ\pom.xml (after > <build><plugins>): What are the immediate advantages of using Maven for XJC source code generation? I'd like the complete source to be checked in in SVN without requiring users to use Maven for building. Can this still be done? > 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: [...] I agree, the missing setters are a drawback when using Spring for configuration. I'll fix this as #1293. I guess, this can be done independently from moving XJC source code generation to the pom.xml: https://sourceforge.net/apps/trac/jooq/ticket/1293 > 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. I was under the impression that this restriction from an older Oracle version was obsolete, which is why I removed that logic. Argument-less user-defined functions can be called with or without empty parentheses: my_func, or my_func(). CURRENT_TIMESTAMP is a bit different, as it is documented as a "function", when in fact it is more of a language-construct: http://docs.oracle.com/cd/B28359_01/server.111/b28286/functions038.htm I hadn't thought of this, so I will fix this as soon as possible: https://sourceforge.net/apps/trac/jooq/ticket/1294 In the meantime, use this: Factory.field("current_timestamp", SQLDataType.TIMESTAMP); If you look at CURRENT_TIMESTAMP as being a language-construct, I think the reason why you cannot set the precision the way you wanted is that this construct accepts no bind values. The correct way to do it is this: Factory.function("current_timestamp", SQLDataType.TIMESTAMP, Factory.literal(6)); or just Factory.field("current_timestamp(6)", SQLDataType.TIMESTAMP); 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 >> >> >> > > >
