Hibernate version: 2.1.4

Hi folks,

I'm using Hibernate on a project with a legacy database and I've run into an issue with polymorphic queries.

I'm trying to load an abstract Prescription class that could be a DrugProduct or DrugCompound concrete type. I know Hibernate can do this via discriminators but being a legacy DB we do not have a proper Type code field we can use.

The legacy code used a substring on the primary key to determine if the type.

Does anyone have any ideas on how I can get around this?

It would be perfect if the discriminators supported UserTypes. I think that would solve my problem. Does Hibernate 3 support discriminator UserTypes. Then I could parse the primary key and provide my own discriminator value.

Thanks in advance guys.

maybe you should provide a "formula" attribute instead of column for discriminator, wait for other members point of view.

In this case, test a patch and wait if it is accepted for jira...

(1) You can write your own DiscriminatorType, just extend the Type hierarchy (its not a usertype, unfortunately)
(2) Use a formula, as anthony says

Anthony, Gavin

Thanks for the advice. My colleague (sperche) and I went with the DiscriminatorType route.. and it works.

For example:

. . .
<discriminator type="com.mycompany.appname.hibernate.types.KeyDiscriminator" column="MY_PRIMARY_KEY" insert="false"/>

. . .


Then my KeyDiscriminator (similiar to String discriminator type) does the get(ResultSet rs, String name) . . and does the appropriate string inspection.

Bingo, polymorphic queries using our legacy DB schema :)

Just one caveat... in our case we only require polymorphic queries for these entities... and did not ever need to do a find by PK using HQL...

(see this post why we do this :)
http://forum.hibernate.org/viewtopic.php?t=933437


I did notice that in the case of loading an entity by its primary key... it uses the discriminator-value when loading the entity. Again, in our case, the discriminator value is really a substring of a primary key value... so it does not work.

Not really a huge issue, however thanks for the advice nonetheless.

I looked at the "discriminator using a formula" route, however it did seem a little more work that using a custom Discriminator type... and didnt require going to resort to native sql substr, substring, etc..


If anyone had any other thoughts on this matter,
always appreciated.

Note: I am still interested in doing a more clean way to express these odd discriminator types... formulas do sound interesting.. and I am getting all too familiar with this Hibernate code... so I may submit it to JIRA

Thanks