> > So, oracle deviates from the sql standard and I can see no way to mask this > behaviour in the current implementation (To do this, village must know > whether an oracle Date column was defined as DATE or TIME in the > schema.xml)
The more I've thought about this, the more I've come to the same conclusion--Oracle deviated from the SQL standard when they advertised DATE columns as SQL type Timestamp. Now that Oracle has a true TIMESTAMP column type, it advertises DATE as SQL Date as it should. But that still doesn't help those who have old Oracle schemas using DATE as a timestamp from the days when that's all Oracle provided. > I'd think that Brendans implementation makes more sense than the current > implementation, but I'd rather not change this in an release cycle. I would certainly at least make it configurable somehow--forcing all Oracle DATE as Timestamp in my patch doesn't seem to be what everyone would want. Mid-release cycle is also probably not a time to change this. > The real solution would be to replace village. Of course. And now that Torque "owns" Village, integrating the code (picking and choosing what we want) would allow tying it to the Torque type from the schema XML would be possible. For now, we will either run with a locally-patched Village, or following every save() of an object that has Oracle DATE columns for which we need timestamp info with an UPDATE query to "fix" the truncated columns. On a row2objects call, however, the java Date members have their timestamp fields truncated again, however. I will end up overriding a lot of methods to cope with this if I opt not to patch Village. Brendan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
