Changing sub-types in NHibernate

Question

I've already read http://stackoverflow.com/questions/478296/nhibernate-changing-sub-types and I don't find that satisfactory to my situation.

My system allows users to schedule jobs. Schedules can be set up with different types of schedule criteria (Once only, Daily, Weekly, Monthly by day of month, and Monthly by week of month). Each of these have very different data and behavior. It is perfectly valid for a user to change a schedule from one criteria type to another.

I attempted to make this work by grabbing the schedule id that was saved previously, creating a new instance of the schedule with the new type, setting the id, and saving. All of the data was updated as expected, except, of course, the discriminator.

Changing my model would be an absolute last resort.

At this point, I am looking at saving the new criteria (with a new id) and updating the references to it, then deleting the old criteria.

Does someone have a better idea?

Answer 1

Have you tried modifing your disciminator mapping to add force=true like the following hbm.xml element

<discriminator column="DiscriminatorColumnName" force="true" />

Answer 2

Since you're already bending the NHibernate view of object identity, why don't you just update it outside of NHib using some custom SQL?

My preferred solution would be to update my model, but you've said that that's a last resort for you.

Answer 3

If you want to use NHibernate, then the concession you must make is:

Write object-oriented code.

If your particular case is arduous to express in an object-oriented manner, then you should not be using NHibernate for that case.

For your case, you should:

• create a new instance of a class deriving Schedule, and permit it to have a new ID
• copy the relevant properties from the old Schedule instance
• delete the old Schedule instance from the Session and ensure that the Job instance in question does not reference it
• add the new Schedule instance to the Session and ensure that the Job instance in question references it

This will end up, at the database level, as a delete and insert, rather than an update.

This is not a last resort. This should have been your first resort. This is the right way to do it from an object-oriented perspective.