Hi,

I have a problem using a date in a composite-id.

In my mapping, object A has a set of B objects. A part of the composite-id of the B object is a date. When trying to get all B objects belonging to an A object, I get an UnsupportedOperationException.

I've checked the code and noticed that this exception is thrown by the getHashCode method of the TimeStampType class. This is implemented very recently. Does this mean I cannot use dates in composite-id's anymore, and if so, why not?

Kind Regards,
Bas ter Brugge


Hibernate version:
Hibernate 3.0a

Mapping documents:

<hibernate-mapping>

<class
lazy="true"
name="nl.ordina.hibernate.test.model.A"
proxy="nl.ordina.hibernate.test.model.A"
table="a"
>

<id
name="id"
type="java.lang.Integer"
column="id"
>
<generator class="assigned" />
</id>

<set
name="bSet"
lazy="true"
inverse="true"
cascade="none"
>
<key>
<column name="id" />
</key>
<one-to-many
class="nl.ordina.hibernate.test.model.B"
/>
</set>
</class>
</hibernate-mapping>


<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping SYSTEM
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd" >

<hibernate-mapping>
<class
lazy="true"
name="nl.ordina.hibernate.test.model.B"
proxy="nl.ordina.hibernate.test.model.B"
table="b"
>

<composite-id name="comp_id" class="nl.ordina.hibernate.test.model.BPK">
<key-property
name="id"
column="id"
type="java.lang.Integer"
length="6"
/>
<key-property
name="date"
column="date"
type="java.util.Date"
length="23"
/>
</composite-id>

<many-to-one
name="a"
class="nl.ordina.hibernate.test.model.A"
not-null="true"
insert="false"
update="false"
>
<column name="id" />
</many-to-one>

</class>
</hibernate-mapping>

Full stack trace of any exception that occurs:

java.lang.UnsupportedOperationException: cannot perform lookups on timestamps
at org.hibernate.type.TimestampType.getHashCode(TimestampType.java:98)
at org.hibernate.type.ComponentType.getHashCode(ComponentType.java:160)
at org.hibernate.engine.EntityKey.hashCode(EntityKey.java:55)
at java.util.HashMap.hash(HashMap.java:261)
at java.util.HashMap.get(HashMap.java:317)
at org.hibernate.impl.SessionImpl.getEntity(SessionImpl.java:506)
at org.hibernate.impl.SessionImpl.getEntityUsingInterceptor(SessionImpl.java:526)
at org.hibernate.loader.Loader.getRow(Loader.java:647)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:270)
at org.hibernate.loader.Loader.doQuery(Loader.java:358)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:190)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1143)
at org.hibernate.loader.OneToManyLoader.initialize(OneToManyLoader.java:103)
at org.hibernate.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:405)
at org.hibernate.event.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:53)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:2277)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:172)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:49)
at org.hibernate.collection.Set.size(Set.java:104)
at nl.ordina.hibernate.test.junit.TestA.testGetA(TestA.java:26)

Name and version of the database you are using:
MySQL 3.23.39-nt and Sybase 12.5

Funny that you mention this as we ran into this just this morning. However, in our case we already knew we wanted to get rid of comp PK and replace it with a surrogate key (damn legacy DBs).

However, the interesting thing to note in our case is that it seemed to using the TimeStampType when the datatype is actually a simple date.

As far as using Timestamps for PKs I would think it's just bad practice as each DB typically handles dates in a slightly different manner and you may not be able to find your records ever again :)

It didn't surprise me to see the unsupported op as I seem to recall Gavin having a strong aversion to ever looking at a TS column. Something along the lines of, actually exact quote :)
"Note that no self-respecting code should EVER call equals on a Timestamp. Its almost as bad as for Float."

Since you would have to do equals when looking up by PK then no self-respecting code should EVER use a Timestamp for a PK :)

I wouldn't have come up with a Timestamp in a primary key either, but sadly enough the datamodel has existed long before I started working on the project. Another good reason for me to have the datamodel changed ;-)



That's what we also noticed.