Hi,
this is my first contribution to this list. I'm evaluating Torque 3.1 for
use in a small (commercial) project with Microsoft SQL Server 2000 as
database. After a few hours I was able to execute the following code
fragment:
Torque.init("Torque.properties");
Office office = new Office();
office.setOfficeName("Test Office 1");
office.setActive(true);
office.setInsDate(new Date());
office.setInsUID("siegel");
office.save();
List offices = OfficePeer.doSelect(new Criteria());
System.out.println("offices = " + offices + "\n");
This worked well. Before going on, I must point out that the INSDATE column
is using database type DATETIME, which stores some fractional seconds, too
(but not at 1 ms precision, it seems to be around 3 to 4 ms precision).
The following code fragment also executed without error, but did not what I
expected:
for (Iterator i = offices.iterator(); i.hasNext();)
{
Office o = (Office) i.next();
System.out.println("deleting " + o.getOfficeID() +
" ...");
OfficePeer.doDelete(o, conn);
System.out.println("... done");
}
offices = OfficePeer.doSelect(new Criteria());
System.out.println("offices = " + offices + "\n");
One would expect that all table rows would have been deleted, but they
still were all there!
After delving into the sources, I found the reason in the DBMSSQL adapter
class, which inherits the getDateString implementation from the DBSybase
adapter class. That implementation cuts off the fractional part of the Date
object. The following modification makes my example code work:
public class DBMSSQL extends DBSybase
{
...
/** date format */
private static final String MSSQL_DATE_FORMAT = "yyyyMMdd HH:mm:ss.SSS"
;
public String getDateString(Date date)
{
char delim = getStringDelimiter();
return (delim + new
SimpleDateFormat(MSSQL_DATE_FORMAT).format(date) + delim);
}
}
This leaves one open ISSUE: the failure to delete the object instance on
the database should not go unnoticed.
A possible solution would be to throw the NoRowsException from the peer
doDelete method. To achieve this goal, it seems to be necessary that the
BasePeer doDelete method return the number of deleted rows as result value
(currently this is a void method, so no problem).
The generated Peer doDelete methods which get an object instance or an
ObjectKey as its parameter would then have to be extended to evaluate the
number of returned rows and throw the proposed exception.
Regards,
Arne Siegel
**********************************************************************
http://www.pta.de
Mit 924 Erfahrungsberichten aus 35 Jahren erfolgreicher Projektarbeit!
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
