Hi! This problem seems to probably be a design flaw that I have created for myself. The client changed requirements midway and I now have a big problem I am not sure how to fix.
My database is a Fleet Management system. The base object is a Vehicle, and then we have multiple child classes of the Vehicle, like Truck, Pickup, Trailers. Pickup is a subclass of Truck. Everything works fine except that the client entered a number of Trucks and did not differentiate between a big rig and a pickup. So now they want to be able to convert those big rigs to pickups.
I made a method that will convert the objects and persist the object back to the database as a pickup, but nHibernate doesn't add a row to the pickup table, so if I try and pull that vehicle back up it sees the object as a truck and not a pickup because it didn't add the row to the Pickup table. And suggestions on this would be appreciated.

What DB Are you using? It seems like it'd be a function for a Stored Procedure.

I am using SQL Server 2000. Originally there was not going to be any changing of vehicle object types, since a truck is always a truck. I never thought about them putting the vehicles in as the wrong type and wanting to change the type.
So are you saying that I should create a stored procedure to create the row in the Pickup table instead of trying to use hibernate to get the change made?

I'm throwing that out there as a possibility. There are multiple ways of doing it, I'm sure; I'm just suggesting one that will hurt the least, IMHO. Sergey, or others that are more well versed in NHibernate may know something I don't. If I were skinning this particular cat, I'd make a SP in the DB and let it handle it at the lowest level possible, rather than drag NHibernate into it. (Since it looks to be a one time change -- once you change them over to a Pickup, you can simply add the new subclass and tweak the mappings to the new objects, yes?)