Hi Peter, Thanks for reporting this. I wasn't aware of such a "flaw" in Oracle's handling of temporal data types within UDTs. I'm afraid that my integration tests currently only cover the SQL DATE type, not the TIMESTAMP type.
I'll try to reproduce your case and see what kind of solution best matches this problem... Could you provide me with some sample DDL to re-create the TABLE/VARRAY of OBJECT that causes issues? Just to rule out that there's some issue related to the array containing the UDT Cheers Lukas 2012/12/1 [email protected] <[email protected]>: > Hi - > > > > The Oracle database that I work with passes Arrays of UDTs that have > date/time values represented as Oracle type DATE. Oracle's DATE resolves > down to the second. When I use jOOQ to generate the corresponding Java class > for the UDT, java.sql.Date is assigned. This class (as documented) truncates > off the hours, minutes, seconds from the date/time. As such - this wont work > as I need to resolve date/times down to the second. > > > > To resolve this issue I applied the jOOQ generator database control of: > > > > <dateAsTimestamp>true</dateAsTimestamp> > > > > That changes the generator to assign java.sql.Timestamp for my date/times. > The code runs until the jOOQ UDTs are converted to Oracle UDTs. The problem > is that the Oracle type in the database expects data to be as a DATE, but > the jOOQ code sets up the corresponding UDT descriptor as a TIMESTAMP rather > than DATE and builds the data structure using TIMESTAMPs (probably because I > told it to do so). This causes the database to kick out a SQLException to > me. > > > > I feel like I'm stuck in a catch-22, java.sql.Date works except for the > missing hour, minute, second parts. Using the for dateAsTimestamp causes the > Oracle UDTs to fail. Are there any workarounds I can put in place to help > with this? Would it be possible to use a custom converter assigned to a UDT? > Or is there a way to define the jOOQ assigned data type to be the > oracle.sql.DATE type? I searched and saw some discussion on this but didn’t > see any solutions. > > > > Thanks, > > Peter
