Это действительно поздно, но может быть полезно следующему человеку, желающему сделать что-то подобное:
В то время как другие ответы верны, вы не должны изменять дискриминатор в большинстве случаев, вы можете делать это исключительно в рамках NH (без собственного SQL), с умное использование сопоставленных свойств. Вот суть использования FluentNH:
public enum CustomerType //not sure it's needed
{
Customer,
TierOneCustomer
}
public class Customer
{
//You should be able to use the Type name instead,
//but I know this enum-based approach works
public virtual CustomerType Type
{
get {return CustomerType.Customer;}
set {} //small code smell; setter exists, no error, but it doesn't do anything.
}
...
}
public class TierOneCustomer:Customer
{
public override CustomerType Type {get {return CustomerType.TierOneCustomer;} set{}}
...
}
public class CustomerMap:ClassMap<Customer>
{
public CustomerMap()
{
...
DiscriminateSubClassesOnColumn<string>("CustomerType");
DiscriminatorValue(CustomerType.Customer.ToString());
//here's the magic; make the discriminator updatable
//"Not.Insert()" is required to prevent the discriminator column
//showing up twice in an insert statement
Map(x => x.Type).Column("CustomerType").Update().Not.Insert();
}
}
public class TierOneCustomerMap:SubclassMap<TierOneCustomer>
{
public CustomerMap()
{
//same idea, different discriminator value
...
DiscriminatorValue(CustomerType.TierOneCustomer.ToString());
...
}
}
Конечным результатом является то, что значение дискриминатора указывается для вставок и используется для определения экземпляра типа при извлечении, но затем, если запись другого подтипа с тем же Id сохраняется (как если бы запись была клонирована или не (связанный с пользовательским интерфейсом к новому типу), значение дискриминатора обновляется в существующей записи с этим идентификатором в качестве свойства объекта, так что будущие извлечения этого типа будут как новый объект. Установщик требуется для свойств, потому что AFAIK NHibernate нельзя сказать, что свойство доступно только для чтения (и, следовательно, «только для записи» в БД); в мире NHibernate, если ты пишешь что-то в БД, почему ты не хочешь вернуть это обратно?
Я недавно использовал этот шаблон, чтобы позволить пользователям изменять базовый тип «тура», который на самом деле представляет собой набор правил, управляющих планированием фактического «тура» (одно цифровое «посещение» клиента -сайтовое оборудование, чтобы все работало нормально). Хотя все они являются «расписаниями туров» и должны собираться в списках / очередях и т. Д. Как таковые, для разных типов расписаний требуются очень разные данные и очень разная обработка, требующая аналогичной структуры данных, как у OP. Поэтому я полностью понимаю желание ОП относиться к TierOneCustomer существенно другим способом, минимизируя эффект на уровне данных, так что здесь все.