[#HHH-405] CalendarType dirty too often with PostgreSQL with patch

Hibernate Core

CalendarType dirty too often with PostgreSQL with patch

Created: 26/Apr/05 11:16 AM Updated: 27/Apr/05 03:39 PM

Component/s:

core

Affects Version/s:

3.0.2

Fix Version/s:

None

Time Tracking:

Not Specified

File Attachments:

calendar-fix.diff (2 kB)

Description

« Hide

While changing some of my Dates do Calendars because of UnSupported getHashCode change I found that my objects with Calendars were being detected as Dirty way too often. I looked into it and it appears that PostgreSQL's JDBC driver actually modifies the Calendar passed in as the 3rd argument to PreparedStatement.setTimestamp(). I don't know if any other JDBC drivers do the same thing but I figured it might be better to clone the calendar passed into setTimestamp anyway. I've included a patch.

Mike

All

Comments

Work Log

Change History

FishEye

Sort Order:

[ Permalink | « Hide ]

Mike Youngstrom added a comment - 26/Apr/05 11:17 AM

Here is the simple patch.

[ Permalink | « Hide ]

Gavin King added a comment - 26/Apr/05 11:25 AM

Negative, this would cause other dbs to be slower. Make Postgres fix the bug.

btw, Hibernate3 CVS has an implemented getHashCode() for TimestampType

[ Permalink | « Hide ]

Mike Youngstrom added a comment - 26/Apr/05 11:46 AM

Didn't realize it was 100% for sure postgreSQL's fault. Reading the javadocs it appears the calendar passed in is supposed to be used to manipulate the timestamp. The javadocs say "cal - the Calendar object the driver will use to construct the timestamp". It says it will use this "object" not a clone of it. I don't have access to any other databases at the moment but I hope it isn't common practice for the JDBC driver to modify the calendar passed in. I'll notify the PostgreSQL guys and see what they say.

Mike

[ Permalink | « Hide ]

Mike Youngstrom added a comment - 26/Apr/05 11:46 AM

[ Permalink | « Hide ]

Mike Youngstrom added a comment - 27/Apr/05 03:39 PM

The PostgreSQL JDBC has fixed the problem. Thanks for pointing me in the right direction.

Mike