I have a mapping file and define an abstract class definition based on a table. I would like to simply create another class which inherits from this one simply to override a couple of properties. However, is this possible, and if so, what is the recommended approach?

in terms of implementing the inheritance in code, i'm assuming you understand all of that. when it comes to the mapping files you have two choices; placing the subclass mappings in the main abstract class mapping file, or separating the subclass mappings into separate files that "extend" the abstract class mapping file.

at a higher-level, though, there are at three basic strategies; table-per-hierarchy, and table-per-subclass, table-per-concrete-class. i personally prefer table-per-subclass because it approaches database normilization standards in a cleaner method. assuming table-per-subclass:





this relies on the the two tables sharing the PK->PK,FK relationship.

look here for more detailed information:

http://www.hibernate.org/hib_docs/nhibe ... nheritance

-devon

Basically, I want to simply extend another class but the derived class still refers to the same table as the parent class. Do I simply use the approach you described, and the table name will be the same for both the parent and subclass?

i see. no, you would be using the table-per-class-hierarchy strategy. in this instance you will have to add a column to your table for the discriminator type of the class and map the file using the <subclass> tag, and yes, you will be storing data from both classes in the same table.

i guess i've hit the kind of restriction I was afraid of here. If all I want to do is redefine some of the parent properties by simple overries in a concrete class, I have to go thru this rigmarole of having to have a discriminator column in order to do a very basic thing.

Now, I did manage to get the behaviour I wanted by simply creating a separate mapping file for my concrete class which only had the properties in it that I was overriding in my parent class. This mapping file had nothing to do with my parent class's mapping file. The only similarity was in the table name, which was the same. this seems to work as when I load a record from the session into my concrete class, i can still persist data using my concrete instance. However, do you think this may be problematic? I need to test this more thoroughly before I can be truly confident this would work.

If I was to use the preferred table-per-class-hierarchy approach and add a dummy discriminator to my table and populate it with one single value for all records, could I trick Hibernate into doing what I want? It seems a shame to have to add a column just to do something like this, but if it allows me to achieve the desired aim, that wouldn't be so bad(altho' getting it past our DBA may require a few beers down the pub!!).

yes absolutely.

'calculated' discriminators are not supported, although you could always use a view ofcourse.

i don't really see an implementation problem with it at all. NH will simply use the mapping file that is associated with it. NH will not understand that the object is derived from another class but i don't think it needs to.