@James:

This is an interesting question and I think it stems from an area where I may not have been all that clear in the video(s) re: the not-null attribute in the mapping elements.

The not-null tag in the mapping file actually has ZERO impact on NHibernate’s behavior — its there for only two reasons: 1) to remind me about how the field is defined in the DB when I’m working with the DTOs and 2) to inform NHib how to generate the schema in the db should I run SchemaExport using these mapping files.

You could certainly prevent the value from being NULL in your property getter/setter or by providing a sensible default value in your classes (and this is REALLY where this business logic belongs in the first place rather than as a default in the DB, IMHO).

I didn’t demo the notion of an Interface or an Abstract Class at the ‘top’ of the inheritance hierarchy tho this is definitely supported; add the abstract=”true” attribute to the class element in the XML to support this implementation and the rest works much the same as demo-ed.

Your point about the discriminator column causing its own perf issues is well-taken and this is one of the main reasons its so damned hard to make recommendation about one strategy for this vs. the other — there are just too many variables to consider as…

1) depth of hierarchy
2) qty of each type in each level of the hierarchy
3) will you be doing much polymorphic querying?
4) are most of your actions inserts or updates?
5) will you mostly be operating on objects at the top, middle, or bottom of the inheritance hierarchy?
6) etc., etc., ett.

The take-away here is: you can change strategies during development without any changes to your data-access-layer, your DTO-consuming code, etc. by just changing your database and your mapping files so experimentation (with real-world scenarios to capture useful benchmarks) is strongly encouraged.

@Corey:

There are a few ways to accomplish this (promotion from Customer to PreferredCustomer) and AFAIK the same challenge will face you if/when you try the same in the table-per-class-hierarchy strategy too (e.g., its not just in joined-sublcass mapped children but also in subclass-mapped children that this issue appears).

It actually turns out that this very topic (in a round-about way) is going to be addressed in the next installment where we talk about evicting entities from the session and then reattaching them. We’ll look @ one way to accomplish this in that installment.

You have to consider that this transformation is viewed by NHibernate as a change from one type of object to another type of object — you see it as a entry in your database, but NHibernate sees it as actually changing an object from one type to another.

If this is something that you see the need to do in your domain model (promote Customers to PreferredCustomers) then the recommended way to accomplish this is offer a method on your Customer class that does exactly this, something with a signature along the lines of…

public PreferredCustomer PromoteToPreferred(Customer c)

…and then in the body of the method instantiate a new PreferredCustomer instance and set all the props on it from the passed-in Customer instance so that the new PreferredCustomer is setup properly and then simply persist this new PreferredCustomer instance and delete the existing Customer instance from the database since its no longer needed.

There is (or should be) no ‘penalty’ for the new PreferredCustomer having a diff PK than the former Customer object since you will be setting all the props on the new object as needed to ensure that FK relations to other objects (tables) in the DB are still enforced.