db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brendan Miller" <bmil...@dotster.com>
Subject Re: Torque 3.3-RC3
Date Mon, 07 May 2007 18:36:48 GMT

I created TORQUE-94 for this issue, BTW.

On Thu, May 03, 2007 at 08:47:04AM -0700, Brendan Miller wrote:
> I just noticed this last week, and have not gotten around to bringing it
> up here, nor filing a jira or thereabouts.
> I observed when calling TablePeer.doDelete(tableObject) for an object
> that had a type="TIMESTAMP" (stored as TIMESTAMP(6) in Oracle), it would
> not find the matching row to delete.  I tracked this down to the SQL
> that was being generated omitted the milliseconds.
> A row in a table with a column called 'ENTRY_TIMESTAMP' has the value:
>     18-APR-07 AM
> as viewed by SQL*Plus.  The generated SQL fragment is
>     TO_DATE('18-APR-2007 03:41:45', 'DD-MM-YYYY HH24:MI:SS')
> as evidenced by DBOracle.java.  This is insufficient to match the
> milliseconds which Village apparently use when inserting the record.  
> To get around this, I have written my own buildCriteria() for these 
> objects that excludes the timestamp fields, but this is a temporary hack.
> Am I on track with this?  Is the fix trivial enough to be included in
> RC3?  I haven't thought about an actual solution, and whether the
> getDateString() needs to have conditional behavior depending on the
> definition of the column (i.e., TIMESTAMP, TIMESTAMP(3), TIMESTMAP(6),
> etc.), but it is an annoyance (and a recent observation).
> Thanks,
> Brendan

To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message