0

Так я следующие объекты:Fluent NHibernate ссылка подкласс

TimelineRecord: 
    ID: PK 
    From: DateTime 
    To: DateTime 

ServiceRecord extends TimelineRecord: 
    ID: PK 
    TimelineRecord_ID: FK 
    SomeSpecificProperties... 

Demand: 
    ID: PK 
    From: DateTime 
    To: DateTime 
    ... 

ServiceDemandConnection: 
    ID: PK 
    Service: ServiceRecord 
    Demand: Demand 

TimelineRecord, спрос и ServiceDemandConnection сопоставляются с использованием ClassMap с идентификатором (х => x.Id). ServiceRecord сопоставляется с использованием SubclassMap (таблица за класс). Ссылки в ServiceDemandConnection отображаются с использованием ссылок (x => x.Service) .Cascade.None() и то же для .Demand.

Проблема заключается в установке ServiceDemandConnection с правильно установленным ServiceRecord и Demand. Я получаю сообщение об ошибке: Detail = Key (servicerecord_id) = (8) нет в таблице «ServiceRecord». Какие состояния ошибок истинны. 8 - идентификатор TimelineRecord, а не ServiceRecord. Однако вместо этого следует использовать идентификатор ServiceRecord (TimelineRecord_ID, который на самом деле не отображается/не доступен в коде). Текущее отображение скрывает ServiceRecord.ID.

Как я могу сказать NHibernate использовать идентификатор таблицы подкласса (ServiceRecord), а не таблицы базового класса (TimelineRecord)? NHibernate фактически создает правильное ограничение в базе данных, но во время выполнения он каким-то образом нарушает его.

ответ

0

Вам нужно либо

  • карта ServiceRecord в отдельный класс не использует SubclassMap использовать это ID
  • или использовать ID от базового класса и не отобразить его в SubclassMap

г. Вторая подход работает, потому что SubclassMap создает связь между дочерним и родительским объектами FK, так что данные не соответствуют istent, и у вас есть что-то вроде

TimeLineRecord 
    ID : PK 

ServiceRecord extends TimelineRecord: 
    TimelineRecord_ID: FK -----> TimeLineRecord.ID 

Он по-прежнему действителен, чтобы указывать ссылки на класс детей.

+0

Я хотел бы сохранить наследство. Второй вариант возможен, но тогда у меня не будет надлежащего ограничения в БД. Любые другие идеи? – wysek

+0

Да, вы это сделаете. Идентификатор со вторым вариантом существует только в базовом классе, а дочерний класс поддерживает только FK для родителя. Это избыточно, чтобы поддерживать идентификацию на обоих уровнях, и это может привести к проблемам. – tchrikch

+0

В _context_proper_ в этом контексте я имел в виду ограничение на ServiceDemandConnection.Service FK. С вашим вторым подходом мне нужно будет изменить тип ServiceDemandConnection.Service с ServiceRecord на TimelineRecord и проверить его достоверность в бизнес-логике. Я что-то упускаю? – wysek