I've searched the forum, and while I've found some threads that were helpful, I didn't come across anything that was close enough to this for me to figure out this mapping.


I have an inheritance heirarchy as follows:



The subclasses are mapped with <joined-subclass> off the Form class. Everything works great.

Now the next form I need to implement is a ContinuingReview/Modification Form. This type of form can be a ContinuingReview only (CR) or a Modification only (MOD) or a combined form. (I know, it's weird). The idea is that the combined form is still only one form and should be treated as such (I want to have one object even if its a combined form). If that wasn't a requirement, I could just add two more <joined-subclasses> for the two new form types and be done.

The initial thought was that I should have two separate tables (one for CR and one for MOD) and have something in the Form table to indicate if this is a CR only, MOD only, or the combined form. And in the case of the combined form, I would retrieve a record from both the CR and MOD tables.

But Hibernate won't be able to do that with the <joined-subclass> mapping (or <subclass> mapping for that matter), because it expects the a Form to be only one of the subtypes (single inheritance) right?

What's the best way to map this example? What I've come up with so far is a <joined-subtype> mapping for a CombinedForm Class which would have a 1:1 properties to both a ModificationInfo class and a ContinuingReviewInfo class. The case where the form is a combined form, both 1:1 relationships have records and obviously if its only one or the other, the one it's not would be null. This way polymorphic queries can still be used to do things like "select all forms for a project" and the like.

Am I way off base on this? Any insight is appreciated.

Regards,
Jay

Just a suggestion...


You then talk about managing the type of the entity (CR, MOD ro combined) by modelling you're current individual requirements explicitly.

You description that I've quoted is an almost exact paraphrase of part of the description of the Composite design pattern (Gang of Four, google it).

Personally, I'd have a read of the pattern and if it fits for your problem, I'd look at refactoring your domain model to move toward the Composite design pattern. I think you'll find this pattern, perhaps in concert with a strategy pattern will make your model much more flexible and possibly even easier to some people to understand (OTOH it might make it harder for other people to understand, but that's life, eh?).

Hibernate can map a composite pattern in a domain model quite easily, it has no problem at all with self/circular references, and I'm sure other people in the forum have done it .

Thanks, I'll check it out.
-Jay