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