[jira] Commented: (TORQUE-94) DBOracle doesn't create proper TO_DATE() clause for TIMESTAMP(6) fields

["CG Monroe (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TORQUE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494290 ] 

CG Monroe commented on TORQUE-94:
---------------------------------

Just to clarify this... I assume that this is only a problem in either of the following two cases:

1) You have created a record object to delete.  E.g.

Record toDelete = new Record();
toDelete.setCol1=value1;
toDelete.setCol2=value2;
RecordPeer.doDelete(toDelete);

Doing deletions this way depends a lot on the default values of the other columns because without a primary key, the SQL generated is a full set of  "where col1= obj.col1 and col2 = obj.col2...." conditions that have to be met exactly (like date fields).   

or 

2) The table involved does not have a primary key defined.  

If I remember correctly, if you call the Peer.doDelete method and the record is not new and has a primary key, the primary key is the only thing used in the where clause.  E.g.  

Delete from table where pk1 = xxx and pk2 = yyy

FWIW, there was some discussion about dropping the do*(Record) methods for Torque 4.0 since it has a lot of "quirks" that make it hard to define a consistent behaviour.



> DBOracle doesn't create proper TO_DATE() clause for TIMESTAMP(6) fields
> -----------------------------------------------------------------------
>
>                 Key: TORQUE-94
>                 URL: https://issues.apache.org/jira/browse/TORQUE-94
>             Project: Torque
>          Issue Type: Bug
>          Components: Runtime
>    Affects Versions: 3.3-RC2
>         Environment: Java 1.5, Oracle 9i
>            Reporter: Brendan Miller
>            Priority: Minor
>
> 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:56', '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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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