Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm
Message-Id: <5.1.0.14.2.20030530122401.04d1f270@mail.snowball.com>
Date: Fri, 30 May 2003 12:24:15 -0700
To: torque-user@db.apache.org
From: Geoff Fortytwo <g42@ign.com>
Subject: RE: TIMESTAMP is being truncated
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Has anyone come up with a solution that doesn't require modifying velocity? 
I'd be willing to modify the code that torque generates (I might be able to 
do that with an ant task so that the problem stays fixed when regenerating 
the code), but I'd really rather not have to mess with the velocity library.


At 03:18 PM 1/31/2003, Juan Perez wrote:
>Well, I originally thought that schema was being used when updating
>and inserting, but after a closer look, the schema is only used for
>creating the torque OM and peer object types. In the case of a DATE
>or TIMESTAMP schema type, a java.util.Date object is getting created.
>
>But regardless of the Torque objects that you create, when updating
>or inserting, the Village classes are used to obtain the type of the
>column in the database using the metadata information from the
>JDBC driver, which is returning type 91, meaning a DATE type, and not
>a 93, meaning a TIMESTAMP type. So 91 is being returned since it is
>getting checked before 93 and a JDBC DATE type is assumed, which
>means that the time is lost.
>
>A change in Record.java from Village can get you around the problem:
>
>private void createValues(ResultSet rs) throws DataSetException,
>         SQLException
>         {
>         for (int i = 1; i <= size(); i++)
>         {
>                 // Don't want to loose time so revert to TIMESTAMP (93)
>                 // instead of DATE (91)
>                 Value val;
>
>                 if (schema().column(i).typeEnum() == 91)
>                         val = new Value (rs, i, 93);
>                 else
>                         val = new Value (rs, i,
>schema().column(i).typeEnum());
>
>             this.values[i] = val;
>         }
>
>The source code for Village can be found at:
>http://share.whichever.com/index.php?SCREEN=village
>
>Does anyone know why the update and insert functions uses Village
>directly and the Torque DBOracle adapter is getting overlooked?
>
>IMHO, the Torque code should take into consideration the schema
>information from the start and not the metadata information when
>updating or inserting to avoid this problem altogether with Oracle
>without having to change the Oracle JDBC driver or making a
>non-generic version of the Village code.
>
>
>-----Original Message-----
>From: Geoff Fortytwo [mailto:g42@ign.com]
>Sent: Friday, January 31, 2003 4:00 PM
>To: Turbine Torque Users List
>Subject: RE: timestamp is being truncated
>
>
>Why would what the driver returns matter? The field type is specified as
>"TIMESTAMP" in the xml schema, so shouldn't that be used regardless of what
>the driver says? In any case, Oracle uses DATE for timestamp and date
>values, so the schema should be where that information gets decided. Right?
>
>At 10:35 AM 1/30/2003, Juan Perez wrote:
> >Hello Steve,
> >As Walt mentioned, the root of the problem is that the Record class in
> >Village
> >is using the metadata type information for the Oracle columns so the
> >problems
> >lies at the JDBC level. Oracle JDBC driver is returning a datatype of DATE
> >which means that the time information is getting lost. This is using
>version
> >
> >9.2.0.1 of the Oracle JDBC driver.
> >
> >
> >
> >
> >-----Original Message-----
> >From: Steve Dobie [mailto:sdobie@vcommerce.com]
> >Sent: Wednesday, January 29, 2003 4:01 PM
> >To: 'Turbine Torque Users List'
> >Subject: RE: timestamp is being truncated
> >
> >
> >I have seen this truncation problem as well, and it seems to be connected
>to
> >the Oracle driver version.  The truncation occurred when we used the Oracle
> >9.2.0 driver, but dates were set with a full timestamp wehn we used the
> >8.1.7 driver.  I am not sure if it is actually a driver bug, or just some
> >change in the drivers between the 8 and 9 versions that Torque has not been
> >updated to accomodate.
> >
> >-----Original Message-----
> >From: Walt Armour [mailto:WaltA@concur.com]
> >Sent: Wednesday, January 29, 2003 1:46 PM
> >To: 'Turbine Torque Users List'
> >Subject: RE: timestamp is being truncated
> >
> >
> >We ran into this also.  I don't have all the details handy but I think it
> >went something like this:
> >
> >We passed in a timestamp at some level.  It got converted into a
> >java.util.Date.  That got passed down through Torque and into Village.
> >Village converted it to a java.sql.Date (as opposed to java.sql.Timestamp).
> >Something after this (possibly the Oracle JDBC driver) considers it just a
> >date and whacks any timestamp portion (if there even is any at this point).
> >
> >So it looks like a fix would need to occur at the village level.
> >
> > > -----Original Message-----
> > > From: Geoff Fortytwo [mailto:g42@ign.com]
> > > Sent: Tuesday, January 28, 2003 1:53 PM
> > > To: turbine-torque-user@jakarta.apache.org
> > > Subject: timestamp is being truncated
> > >
> > >
> > > When I save timestamps, the values are truncated to dates.
> > >
> > > The field declaration in the schema is:
> > >    <column
> > > name="whenAdded"   javaName="WhenAdded"   required="false"
> > > type="TIMESTAMP"/>
> > > when I set the timestamp I do:
> > >    profile.setWhenAdded( new
> > > java.sql.Timestamp(System.currentTimeMillis()) );
> > > I've also tried
> > >    profile.setWhenAdded( new
> > > java.sql.Date(System.currentTimeMillis()) );
> > > and
> > >    profile.setWhenAdded( new
> > > java.util.Date(System.currentTimeMillis()) );
> > >
> > > No matter what, the date is saved to the database with the
> > > time truncated
> > > so that only the date part of the timestamp is saved.
> > >
> > > I've put trace statements into the code and the value is definitely a
> > > timestamp before and after I save the record, but when the record is
> > > reloaded it's truncated. If I look at the value directly in
> > > the database,
> > > it's always truncated after I insert it with torque. If I do the same
> > > insert using a sql INSERT statement it saves the time in the
> > > field, so
> > > there isn't anything in the database that's forcing the truncation.
> > >
> > > I'm using Oracle with Torque 3.0. I tried tracing the code
> > > through the
> > > entire insert, but I get to the point where it goes into
> > > village and I
> > > don't have that code. I suppose I could download it, but I'm
> > > not sure I can
> > > figure this out. Does anyone have any ideas?
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:turbine-torque-user-> unsubscribe@jakarta.apache.org>
> > >
> > > For additional commands,
> > > e-mail: <mailto:turbine-torque-user-help@jakarta.apache.org>
> > >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: turbine-torque-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
>turbine-torque-user-help@jakarta.apache.org
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: turbine-torque-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
>turbine-torque-user-help@jakarta.apache.org
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: turbine-torque-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
>turbine-torque-user-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-torque-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-torque-user-help@jakarta.apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-torque-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-torque-user-help@jakarta.apache.org