I have a question regarding inheritance and object loading. Here's an abstract example:

class Person;
class Employee : Person;
class Manager : Employee
class SalesPerson : Employee

This would be mapped using the joined-subclass strategy such that all data common to all Person types is stored in the Person table and "table inheritence" is used for each Person type-specific data.

Now, here's my question: say I have the following mapped object:


(Essentially, a LineOfBusines would have Employees doing the work, Managers managing the Employees, and SalesPeople that are assigned to "sell, sell, sell" the services of the LineOfBusiness...)

When I try this, I get an error when a Person object is loaded that is both a SalesPerson and a Manager, when using Session.Load(typeof(LineOfBusiness), someId).

Is this possible with NHibernate? I realize that my "LineOfBusiness" example isn't that great and I can try to elaborate on it if need be.

Thanks for any suggestions.

As a collegue of mine pointed out, the error doesn't occur until the Lists are actually loaded, in the case when lazy="true" for those one-to-many relationships...

Thanks again.

IMO, if a Person can be a SalesPerson and a Manager; then you should change your inheritance model...

Thanks for you're reply. Since it's easier to ask for forgiveness than permission, here's my actual problem:



On a report, a column can be any combination Display, Filter, and Sort Column types. However, when I try Session.Load(typeof(Report), reportId) and load the lists, if a DisplayColumn is also a FilterColumn I get the NHibernate error I previously described.

Granted, this may be a bad design and, if that's the case, I'm open to suggestions. However, can this be handled in NHiberate? Also, is there a test case in the source that I could look at for more information or take as an example?

Thanks so much.

H

I see several options here:
- don't map BaseColumn class at all, pretend it doesn't exist
- use composition instead of inheritance, that is, use only one big class instead of the three subclasses.

As it is now, the hierarchy doesn't make much sense since if BaseColumn is an entity, there can only be one BaseColumn with a given id by definition (identifiers are used to uniquely identify an object/entity/database record, after all).