[ANNOUNCEMENT] Release 2.0 with many major improvements released !
Lukas Eder
issues that have been requested by users for a long time. These
release notes document the most important changes, a detailed
upgrade guide, as well as the detailed list of improvements.
For full details, please visit the release notes page:
http://www.jooq.org/notes.php
Most important changes
----------------------
- The API became more static. This applies to many Factory
methods, such as val(), literal(), as well as to many Field
methods that have been moved over to the Factory. For example,
when before, you wrote this using "postfix function notation":
<pre>NAME.replace(" ", "_").trim()</pre>
you will now write (just as in SQL):
<pre>trim(replace(NAME, " ", "_"))</pre>
Using static imports of Factory.*, jOOQ makes SQL look even
more like SQL. The current "postfix notation" is maintained for
backwards compatibility.
- By default, jooq-codegen will now generate a "dynamic" meta
model as opposed to the existing static one. Generated tables
covariantly override the as(String) aliasing method, leading
to a much more convenient aliasing style. When before, you
wrote:
Table<TRecord> parent = T.as("parent");
Table<TRecord> child = T.as("child");
Condition join =
parent.getField("ID").equal(child.getField("PARENT_ID"))
You can now write:
T parent = T.as("parent");
T child = T.as("child");
Condition join = parent.ID.equal(child.PARENT_ID)
Of course, the existing notation still works
- Exceptions are no longer checked. When previously, the DB's
SQLException was propagated to client code, there is now an
unchecked DataAccessException hierarchy, similar to that of
Spring. This will eventually give way to a standardised error
handling abstraction, in future developments
.
- Window functions are now constructed from their underlying
aggregate functions just like in SQL. For example:
sum(AMOUNT)
sum(AMOUNT).over().partitionBy(ACCOUNT)
This makes for a more concise API, especially when considering
future extensions, such as Oracle's KEEP (DENSE_RANK FIRST...)
syntax.
- More type safety has been introduced regarding various places
where generic <R extends Record> and <T> types are involved.
This is especially true for INSERT / UPDATE / DELETE statements
- Sequences now also have a <T> type
- Unsigned number types are now supported in those databases that
use them. Unsigned numbers are implemented in jOOU, a spin-off
open source project. For convenience, this library is
"internalised" into jOOQ, to avoid adding a dependency
http://code.google.com/p/joou/
Upgrade instructions:
---------------------
Various of the above changes are incompatible with jOOQ 1.x. In
order to upgrade, please be aware of the following pitfalls:
- The schema needs to be re-generated.
- Much of the post-fix function notation is replaced by static
methods in the Factory. Today's org.jooq.Field API is
maintained in jOOQ 2.0, for backwards compatibility. It will
be removed, eventually, though. Expect some incompatible
changes, where window functions are involved
- Some Factory instance methods (such as val(), literal()) are
now static. They are compatible, but may cause compiler
warnings.
- The meta model is now an instance model by default. If you
prefer the static meta model, you can configure this in your
jooq-codegen configuration.
- The additional typesafety involving <R> and <T> types may cause
compiler warnings and errors.
- SQLException is no longer part of the API. This can cause
compiler issues, in particular when extending jOOQ
- Some utility classes have moved to org.jooq.tools
Should these incompatibilities be too significant for your
project, you can still stay on the 1.x branch, which will be
maintained for a while. Be aware that upgrading might be more
difficult, later, though.
Rakesh Waghela
Any direct download link to get JOOQ from Jooq.org or github ?
Lukas Eder
You mean some proxy / gateway blocks access from source forge?
Unfortunately, there is no other download for builds, except if you
want to build jOOQ yourself using Maven? You could get the source from
SourceForge SVN / Github Git
Cheers
Lukas
2011/12/1 Rakesh Waghela <java...@gmail.com>:
Sander Plas
Lukas Eder
http://repo1.maven.org/maven2/org/jooq/
2011/12/1 Sander Plas <sande...@gmail.com>:
Rakesh Waghela
Lukas Eder
I just realised: I haven't mentioned the jOOQ-Spring SVN project yet.
Neither did I release it officially. The reason is, I'm not sure if
the current jOOQ-Spring is general enough for broad usage. To me, it
leaves a lot of open questions about how to use it, how to document
it, etc. I guess I would need to see it in action, first...? If I
should officially support such an extension, then I'll need ideas
about how to integration-test it, and extend it in future
developments.
Note, jOOQ-Wicket was a similar contribution, which I never released
so far, for the same reasons.
Cheers
Lukas
2011/11/27 Lukas Eder <lukas...@gmail.com>:
Lukas Eder
> 1. At this moment Record.from copies values from bean to record and does all
> value "changed".
> For example, we read fresh record from database and apply changes using
> Record.from from some bean.
> After that all fields including primary key marked as "changed" and
> Record.store tries to insert record instead of update.
> Is it reasonable copy only different values?
Nice hint. I'll think about this. I agree that the primary key (or
"main unique key") shouldn't be flagged as changed for the reasons you
mentioned. I think this is checked elsewhere, already. For the other
fields, it might be good to set them in updates as well, though:
1. to avoid potentially stale values not being set
2. to increase performance because of fewer soft-parses in the DB.
There will be only one possible UPDATE statement per table, instead of
O(n^2) for all combinations of changed fields.
I'll file this as
https://sourceforge.net/apps/trac/jooq/ticket/979
It'll be included in 2.0.1
> 2. FactoryProxy creates new instance of Factory for each request. So
> QueryParts created from different threads should reference different Factory
> (Configuration) instances..
Perfect. Then you should be safe.
Cheers
Lukas
2011/12/6 Sergey Epik <serge...@gmail.com>:
> Hello Lukas,
>
> 1. At this moment Record.from copies values from bean to record and does all
> value "changed".
> For example, we read fresh record from database and apply changes using
> Record.from from some bean.
> After that all fields including primary key marked as "changed" and
> Record.store tries to insert record instead of update.
> Is it reasonable copy only different values?
>
> Here is possible change in Util.setValue:
>
> static final <T> void setValue(Record target, Field<T> targetField,
> Object value) {
> T newValue = targetField.getDataType().convert(value);
> T oldValue = target.getValue(targetField);
> boolean equals = (newValue != null && newValue.equals(oldValue)) ||
> (newValue == null && oldValue == null);
> if (!equals) {
> target.setValue(targetField,
> targetField.getDataType().convert(value));
> }
> }
>
> 2. FactoryProxy creates new instance of Factory for each request. So
> QueryParts created from different threads should reference different Factory
> (Configuration) instances..
>
> Best regards,
> Sergey
>
>
>
> On Mon, Dec 5, 2011 at 10:19 AM, Lukas Eder <lukas...@gmail.com> wrote:
>>
>> Hi Sergey,
>> > 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.
>> Hmm, maybe at this point I need to warn you that QueryParts created
>> from a Factory are not thread-safe either. They are "attached" through
>> the org.jooq.Attachable interface. You shouldn't use the same
>> org.jooq.Query instance in different threads, or their underlying
>> factories / connections might get mixed up!
>> I'm having a closer look at your updated jOOQ-spring project and your
>> links later
>>
>> Cheers
>> Lukas
>> 2011/12/4 Sergey Epik <serge...@gmail.com>:
>> > 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
Oliver Thomsen
provided?
Regards, Oliver.
Lukas Eder
Lukas Eder
https://github.com/lukaseder/jOOQ/commit/0bedfea90f883f5e70bbc8f4b3fadb52cfa164fc
Version 2.0 is SVN revision 1593.
Thanks for pointing this out
Cheers
Lukas
2011/12/7 Lukas Eder <lukas...@gmail.com>:
Oliver Thomsen
On Dec 7, 9:32 pm, Lukas Eder <lukas.e...@gmail.com> wrote:
> Done. Fortunately, This was documented in the commit logs:https://github.com/lukaseder/jOOQ/commit/0bedfea90f883f5e70bbc8f4b3fa...
>
> Version 2.0 is SVN revision 1593.
> Thanks for pointing this out
>
> Cheers
> Lukas
>
> 2011/12/7 Lukas Eder <lukas.e...@gmail.com>:
>
>
>
>
>
>
>
> > Hmm, that's missing.
> > I'll create it ASAP!
>
> > 2011/12/7 Oliver Thomsen <late...@googlemail.com>:
Lukas Eder
> > 1. At this moment Record.from copies values from bean to record and does all
> > value "changed".
> > For example, we read fresh record from database and apply changes using
> > Record.from from some bean.
> > After that all fields including primary key marked as "changed" and
> > Record.store tries to insert record instead of update.
> > Is it reasonable copy only different values?
>
> Nice hint. I'll think about this. I agree that the primary key (or
> "main unique key") shouldn't be flagged as changed for the reasons you
> mentioned. I think this is checked elsewhere, already. [...]
After some analysis, I think this issue got introduced as a regression with
https://sourceforge.net/apps/trac/jooq/ticket/945
There was some subtlety involved with setting a value twice to the
same value, resulting in the changed flag to be reset. I guess the
above fix was wrong.
Cheers
Lukas
Lukas Eder
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 <serge...@gmail.com>:
> 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 <lukas...@gmail.com> 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 <serge...@gmail.com>:
>> > 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.
Lukas Eder
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);
Lukas Eder
I'm cc'ing to the user-group, as always, to share your thoughts with
other users. There tends to be good feedback on rather fundamental
issues like this one:
> It's a good practice. It simplifies configuration, generated source code is
> always up to date, nobody can change it and commit.
> You do not have keep jar files on source control, etc.
> Modern IDE's understand maven life cycle and include generated source code
> to classpath, so I do not see any problem here.
I'm not sure if everyone will agree on this. If you need to explicitly
add M2E as a plugin to your Eclipse project to generate sources needed
in jOOQ, some users will probably hate me for that :-) For non-Maven
users (there are many, include me as a matter of fact, M2E kills my
CPU), it is already quite a pain to manually add the dependencies. So
I'm really interested only in solutions where in the end,
XJC-generated source code can be checked in to trunk. This source code
doesn't change a lot, so I don't need to re-generate it every time.
On the other hand, moving the generation from ant to the pom.xml is
fine with me, if I can make this a one-shot generation, which is not
part of the build-deploy process.
> Another question how to generate jOOQ classes during build process.
> Unfortunately we have keep classes, generated by jOOQ , on source control at
> this moment. We already discussed before that we need two phase generation.
> One phase - database introspection, the result (mediated database model) can
> be kept on source control (in xml format, for example), run manually, on
> demand.
> The second phase - generation code from model during build process.
Yes, we had discussed this. It is still on the road map, but hasn't
been a priority so far. The favoured solution is -as you put it- to
use jooq-meta/jooq-codegen to generate XML output from the schema
instead of Java output. Then to use jooq-meta/jooq-codegen again, to
use the XML input rather than a database and generate the Java output
from there.
Any contributions would be very welcome, most importantly an XSD
defining the XML file. I had raised the question on Stack Overflow,
without success so far:
http://stackoverflow.com/questions/8184849/is-there-a-sql-information-schema-xsd-definition
Cheers
Lukas
2012/4/10 Sergey Epik <serge...@gmail.com>:
> Hello Lukas,
>
> On Tue, Apr 10, 2012 at 10:35 AM, Lukas Eder <lukas...@gmail.com> wrote:
>>
>> 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?
>
>
> It's a good practice. It simplifies configuration, generated source code is
> always up to date, nobody can change it and commit.
> You do not have keep jar files on source control, etc.
> Modern IDE's understand maven life cycle and include generated source code
> to classpath, so I do not see any problem here.
>
> Another question how to generate jOOQ classes during build process.
> Unfortunately we have keep classes, generated by jOOQ , on source control at
> this moment. We already discussed before that we need two phase generation.
> One phase - database introspection, the result (mediated database model) can
> be kept on source control (in xml format, for example), run manually, on
> demand.
> The second phase - generation code from model during build process.
>
>> 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));
>
>
> Thank you, it works!
Lukas Eder
>> It's a good practice. It simplifies configuration, generated source code is
>> always up to date, nobody can change it and commit.
>> You do not have keep jar files on source control, etc.
>> Modern IDE's understand maven life cycle and include generated source code
>> to classpath, so I do not see any problem here.
I'm going to try your suggested solution. I'll be looking for the
right way to put generated sources in version control, but in general
it probably makes sense to move source code generation from ant to
Maven.
Thanks for your contribution!
Cheers
Lukas
2012/4/10 Lukas Eder <lukas...@gmail.com>: