Блог

У меня возникла проблема при попытке отобразить отношения «многие ко многим», где обе стороны отношения ссылаются на одну и ту же сущность. Я использую Fluent NHibernate и NH3.1.

В принципе, сценарий таков — у меня есть категория, у которой может быть несколько родителей. Таким образом, категория имеет несколько других категорий в качестве родителей, а также несколько других категорий в качестве своих дочерних элементов.

 HasManyToMany(x => x.ParentCategories).AsBag().Table("parentcategorychildren").ParentKeyColumn("ChildID").ChildKeyColumn("ParentID").Cascade.SaveUpdate();
HasManyToMany(x => x.ChildrenCategories).AsBag().Table("parentcategorychildren").ParentKeyColumn("ParentID").ChildKeyColumn("ChildID").Inverse();
  

Однако, когда я пытаюсь создать фабрику, я получаю следующую ошибку:

Категория отношений.Дочерние категории для категории.ChildrenCategories имеет обратное значение с обеих сторон. Удалите инверсию с одной стороны отношения.

Что я нахожу странным, так это то, почему в нем упоминается «Категория.Дочерние категории ‘ для категории.Дочерние категории, в отличие от родительских категорий?

Любая помощь была бы с благодарностью!

Я только что создал награду за это, потому что это достаточно важно для меня. Пожалуйста, меня не интересует «вы не можете этого сделать» в качестве ответа.

Скорее всего, это ошибка FNH, и, скорее всего, она уже исправлена в последнем исходном коде FNH. При использовании FNH1.0 и NH2.1 проблем нет. Эквивалентное сопоставление HBM хорошо работает в FNH1.2 и NH3.1:

 <bag name="ParentCategories" cascade="all" table="parentcategorychildren">
    <key column="ChildID" />
    <many-to-many column="ParentID" class="Category" />
</bag>

<bag name="ChildrenCategories" inverse="true" table="parentcategorychildren">
    <key column="ParentID" />
    <many-to-many column="ChildID" class="Category" />
</bag>
  

Редактировать:
Покопавшись в исходном коде FNH, я нашел обходной путь. Допустим, ваша конфигурация выглядит следующим образом:

 .Mappings(m => {
    m.FluentMappings.AddFromAssemblyOf<Category>();
})
  

Неудачный код может быть подавлен этой конфигурацией:

 .Mappings(m => {
    var persistenceModel = new PersistenceModel();
    persistenceModel.AddMappingsFromAssembly(typeof(Category).Assembly);
    persistenceModel.ValidationEnabled = false; // this makes the trick
    m.UsePersistenceModel(persistenceModel);
})
  

Это проблема с проверкой / сопряжением отношений в Fluent NHibernate 2.1. FNH объединяет отношения в пары, а затем проверяет, .Inverse() указана ли только одна сторона отношения. Поскольку обе ссылки (родительская / дочерняя) относятся к одному и тому же классу, они оба являются кандидатами на совпадение при сопряжении. В этом случае FNH совпадает по сходству имен. Следовательно, каждый из них соединяется с самим собой, а не друг с другом. Итак, затем размещение .Inverse() на любом из них запускает проверку (обе стороны пары представляют собой одинаковые отношения, которые являются обратными).

Должно быть возможно исправить это с помощью OverrideBiDirectionalManyToManyPairing() метода в FluentMappingsContainer. Теоретически, это позволило бы вам явно связать дочерние и родительские отношения. Однако в FNH 2.1 есть ошибка, и обратный вызов переопределения никогда не вызывается. (Значение обратного вызова фиксируется до того, как оно может быть установлено методом).

В качестве обходного пути вы можете отключить всю проверку в FNH. Существует только две проверки. Во-первых, этого не имеют обе стороны отношений .Inverse() . Во-вторых, для каждой сущности сопоставляется идентификатор. Самый чистый способ, который я нашел, отключить проверку, это:

 .Mappings(m => {
    var persistenceModel = new PersistenceModel() { ValidationEnabled = false };
    m.UsePersistenceModel(persistenceModel)
     .FluentMappings.AddFromAssemblyOf<Category>();
})
  

Этот подход позволяет отключить проверку, но при этом использовать полную выразительность FluentMappings конфигурации.

Да, мне показалось, что это, скорее всего, ошибка в FNH, поскольку я попробовал это напрямую с NHibernate без использования Fluent NH, и это сработало. Однако, поскольку я уже настроил систему с использованием FNH, я не мог просто отказаться от ее использования.

Что я сделал, так это то, что я сам создал что-то вроде «класса посередине» для отношения «многие ко многим», которое обычно генерируется автоматически. Я создал ContentPage_ChildLink страницу, которая связала категории Parents и Children . Это позволило мне работать с FNH и обойти проблему 🙂

В основном это ContentPage_ChildLink будет иметь два поля, ChildID и ParentID . Затем я мог бы установить «обратные» отношения отдельно, без каких-либо проблем.

Проблема с FNH, похоже, заключалась в том, что когда у вас есть отношения «многие ко многим», обе стороны которых являются одним и тем же классом, единственный случай, о котором я могу думать, — это иерархическая структура, которая допускает несколько родителей.