> For the oracle.sql types, it is a configuration parameter to use those types > and was a design decision. [...] Using double mapped > to BINARY_DOUBLE (IEEE-754) solved this as there should be no translation > between Java's Double and BINARY_DOUBLE (they are both IEEE-754).
I see. > Oracle > also had some time zone issues with Date objects going in so a decision was > made to stick with the oracle.sql types and handle the type mapping in our > code. I'm not sure if this is the same problem, but I've recently had "trouble" with this as well. It turned out to be some subtlety of the JDBC specification, which doesn't map well to Oracle's non-standard implementation of DATE/TIMESTAMP. But after all, it was my misunderstanding of JDBC. Here's some more insight: http://stackoverflow.com/questions/9202857/timezones-in-sql-date-vs-java-sql-date > Here is the mapping of your sample package. I see, so they've had their own thoughts for method name disambiguation. I'll think of something to properly disambiguate these cases. Maybe, I'll add some methods to the GeneratorStrategy as documented here: http://www.jooq.org/manual/META/AdvancedConfiguration/ It might be useful for PL/SQL power users, to be able to influence this section of the generated code more specifically Thanks for your help! Lukas
