Done. The issue name is: Bad dates persisted in Oracle 9.2 Regards, August ----- Original Message ---- From: Werner Guttmann <[EMAIL PROTECTED]> To: dev@castor.codehaus.org Sent: Sunday, March 5, 2006 1:12:46 PM Subject: Re: [castor-dev] How are Dates inserted/updated in Castor?
August, can I please ask you to create a new issue at http://jira.codehaus.org/browse/CASTOR, and attach your patch (for review) as well as the relevant parts of this conversation. Regards Werner Guttmann August Detlefsen wrote: > Thanks Ralf for the clues. I've finally had the time to do a bit more digging > into this. Apparently there was a change in the way Oracle handles dates and > timestamps internally at version 9.2. I think the issue I am seeing with bad > dates is related to this. > > According to the Oracle JDBC FAQ this could cause trouble for applications > that map date to timestamp or vice versa: > > > http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq.htm#08_01 > > The FAQ says that one possible solution is to use getTimestamp rather than > getObject in the JDBC code (I assume the same is true for set methods, ie. > use setTimestamp instead of setObject). I have modified SQLTypes.java to > explicitly use setTimestamp and setDate when dealing with these object types > and I am currently testing the new implementation (Patch attached). > > Do you see any potential issues with this approach? > Would this be a candidate for inclusion in the main castor source if the > tests are successful? > > Regards, > August > > > > ----- Original Message ---- > From: Ralf Joachim <[EMAIL PROTECTED]> > To: dev@castor.codehaus.org > Sent: Friday, January 6, 2006 12:58:16 PM > Subject: Re: [castor-dev] How are Dates inserted/updated in Castor? > > Hi August, > > depending on the column type in your database and the mapping you > specified the java.util.Date is converted to java.sql.Date, > java.sql.Time, java.sql.Timestamp, java.lang.Long or java.lang.String by > castor. Maybe there are some alternatives i missed here. This values are > then passed to the JDBC driver to be stored in the database. > > If I would have had more information like mapping and DDL-script or > better a test case, I would have had a better chace to give you > valueable hints. > > Having said that there is the posibility to log the sql statements > passed to the JDBC driver which could really help yourself to isolate > the problem. To enable the debugging with castor 0.9.9.1 or 1.0M1 you > need to: > > - set 'org.exolab.castor.persist.useProxies=false' to true in > castor.properties file. > - set logging level of 'org.exolab.castor.jdo.drivers.ConnectionProxy' and > 'org.exolab.castor.jdo.drivers.PreparedStatementProxy' to debug. > > This will allow you to take a look on the SQL-statements castor sends to > the JDBC driver. > > Regards > Ralf > Castor JDO, committer > > > August Detlefsen schrieb: > >> I've recently been having some trouble with bad dates being inserted into >> our Oracle 9i database and we are trying to figure out whether this is being >> caused by the database itself or something in the application code. The >> issue is that dates are being inserted either very far in the future or very >> far in the past: >> >> When the Object in question is modified, we create a new java.util.Date and >> set it in the object before committing: >> >> Date modifiedDate = new Date(); >> >> theObject.setModifiedDate( modifiedDate ); >> >> db.commit(); >> >> This should update the modified date to the current date, but instead we are >> seeing modified dates all the way up to the year 2030, and down to 2030 BC! >> >> Can anyone give me some information about how Castor handles Date >> inserts/updates? This will help me isolate where the problem is coming from: >> Application code, castor, the JDBC driver, the Oracle database itself, etc. >> >> Thanks, >> August >> >> >> >> ------------------------------------------------- >> If you wish to unsubscribe from this list, please >> send an empty message to the following address: >> >> [EMAIL PROTECTED] >> ------------------------------------------------- >> >> > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
