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 Thu, 03 May 2007 15:47:04 GMT
On Thu, May 03, 2007 at 02:33:49PM +0200, Thomas Vandahl wrote:
> I would like to call a vote on Torque 3.3-RC3 in the near future. I
> should be hopefully the last RC before final release. Is there anything
> that needs to be fixed before?

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 03.41.56.705000 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


Mime
View raw message