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.
|Transition||Time In Source Status||Execution Times||Last Executer||Last Execution Date|
|1729d 1h 16m||1||Thomas Fox||30/Jan/12 19:53|
|237d 11h 13m||1||Thomas Fox||24/Sep/12 08:06|
|Status||Resolved [ 5 ]||Closed [ 6 ]|
|Status||Open [ 1 ]||Resolved [ 5 ]|
|Assignee||Thomas Fox [ tfischer ]|
|Fix Version/s||4.0 [ 12312102 ]|
|Resolution||Fixed [ 1 ]|
|Field||Original Value||New Value|
|Affects Version/s||3.3-RC1 [ 12312227 ]|
|Affects Version/s||3.3-RC2 [ 12312370 ]|