Re: Hibernate, JBoss, PostgreSQL, timestamp read doesn't match during update
От | Roland Roberts |
---|---|
Тема | Re: Hibernate, JBoss, PostgreSQL, timestamp read doesn't match during update |
Дата | |
Msg-id | 49C43655.6040808@astrofoto.org обсуждение исходный текст |
Ответ на | Re: Hibernate, JBoss, PostgreSQL, timestamp read doesn't match during update (Roland Roberts <roland@astrofoto.org>) |
Список | pgsql-jdbc |
Roland Roberts wrote: > Roland Roberts wrote: >> I've got some more poking I can do. Java doesn't seem to have a way >> of printing microseconds for timestamps with, for example, >> SimpleDateFormat, but I should be able to see if it can at least >> retrieve them. > I modified HibernateUTC$Timestamp, my UserVersionType class, to have > it use log4j to tell me exactly what the timestamp is immediates after > the rs.getTimestamp() call. The extra precision is there. > > 20:01:21,756 INFO [STDOUT] Hibernate: select security0_.id as id1_, > security0_.active_on as active2_1_, security0_.primary_identifier as > primary3_1_, security0_.identifier_type_code as identifier4_1_, > security0_.security_type_code as security5_1_, security0_.issue_name > as issue6_1_, security0_.issuer_name as issuer7_1_, > security0_.industry_name as industry8_1_, security0_.exchange_code as > exchange9_1_, security0_.mic_code as mic10_1_, > security0_.def_sector_code as def11_1_, security0_.icb4_code as > icb12_1_, security0_.def_gdr_security_id as def13_1_, > security0_.is_live as is14_1_, security0_.shares_outstanding as > shares15_1_, security0_.last_price_modified_time as last16_1_, > security0_.last_price_time as last17_1_, > security0_.last_price_validated_time as last18_1_, > security0_.active_until as active19_1_ from drpg.Security security0_ > where primary_identifier=? limit ? > 20:01:21,767 INFO [HibernateUTC] got timestamp 2009-03-20 > 20:00:59.526338 nanos=526338000 > 20:01:21,768 INFO [HibernateUTC] got timestamp 2009-03-20 20:00:59.6 > nanos=600000000 > > I'm not through poking, but at least I know where the problem isn't. Aarrgh! User error. The application copies the timestamps inside the setter by creating a new one: myval = new Timestamp(old_timestamp.getTime()); which only copies down to the milliseconds. roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland@rlenter.com 6818 Madeline Court roland@astrofoto.org Brooklyn, NY 11220
В списке pgsql-jdbc по дате отправления: