If we are implmenting inheritance via the table-per-hierarchy (<subclass>) or table-per-subclass (<joined-subclass>) strategies then it appears, at least from all the samples that I have seen, that the mapping definitions for the subclasses must all be embedded into the mapping definition of the super class.

Is this correct? If so is there anyway around this? It seems that on some multilevel hierarchies this single mapping file is going to get awfully large and complex.

I just found it a bit confusing because I've read in a couple of places that we should create a separate mapping file for each class (and I agree with this approach) but maybe this doesn't/can't apply to inheritance. Maybe this only refers to top level super classes. All subclasses must be defined in their ultimate superclass' mapping file.

Has anyone got any ideas about this one?

my editor doesn't complain ...

It's not so much a problem with my editor - just a question of styling and strategy. I can make it work by embedding all subclasses into the super classes mapping file but was hoping there was a solution where I could stick to the "one class per mapping file philosophy". Using this "embed subclass in super class" strategy in Java would have meant including every subclass in my super class' .java file - which would be a big no, no because you want to make it possible for anyone to subclass a Java class without changing the super class.

Heh! You know what would be really cool?:

If the DTD was changed so that subclassing was turned upside down to make it more like in Java and C++ - ie., the super class doesn't have any knowledge of the subclasses. (obviously Hibernate will know at run time because it finds "extends" links in the subclass files but at map definition time the developer doesn't have to list every subclass in the super class).

So instead of a super class' mapping file having to list all of its subclasses it simply maps itself. Then, in each of the subclass mapping files we use the existing "extends" element to make a reference to the super class's name.

That idea is so crazy that it might just work... :)

Well of course we'd have to get JBoss to change the DTD and possibly some Hibernate code but it shouldn't be too hard to do - we're not changing any Hibernate core functionality, just adding a new way of declaring subclasses.

i think the editor may have thrown you off. the editor does DTD validation, so this if totally OK. you can put a classpathreference to the above file in hibernate.cfg.xml and the class will be mapped afaik. try it.

Ok, that's great I think.

So you can put the subclass straight into its own mapping file and use the extend element to say which class it extends?

Kewl!

yes, the subclass element has an extends attribute and it will work on it's own, as long as you remember to load the mapping file that is holding the parent as well.

... or you can switch to annotations and the whole thing doesn't matter that much.

Are annotations mature enough to use yet?

Does it mean switching to Java 1.5?

I don't have too many problems w/ them ... and you will have to switch to 1.5 .

Thanks for that. That's made everything so much more neat!

On another note:

Which inheritance strategies do you tend to use more?

1. Table per hierarchy
2. Table per subclass

The other options look a bit extreme.

I have only used table per class hierarchy. not recommended unless you have serious performance requirements, or maybe the data model is out of your control.

If if I'm doing a new design to my own tasks and I don't have performance issus then I should steer clear of table per hierarchy?

table per subclass seems very nice.

table per class hierarchy is used when you want to cram 5 or 10 related entities into one table. not clean. but, when there are 4 million of them, you can't afford to do the join .

table per subclass lends itself more naturally to the object oriented way of doing things.

Oh good. The object oriented way of doing things is what I've been doing since picked up my first C++ compiler 15 years ago. I wouldn't want to go changing things now!

I just had another question regarding packaging. Hope you don't mind =]

I've been using the package option in the <hibernate-mapping> tag with no problems but I thought, "What if a super class is in a different package?" Can we supply a full packaged name where ever the mapping file expects a class name or is there another way to supply the package name?

ie., have been using class="MyClass" but can I use class="com.blah.de.bla.MyClass"?

If the <hibernate-mapping tag also has the package option set what will happen? Will that one get ignored?

if all of your classes are in the same package, you'll want to just put the package name in the package attribute of hibernate-mapping and H will assume that is the package for every Class in that mapping document.

if you want a more complex domain model, you will need to use the fully qualified names of Classes that are outside the package specified in the package attribute of hibernate-mapping.