Запрос Nhibernate с нулевым ядром

Question

Мне нужно вернуть всех пользователей с действительным свойством Wish (так же, как и null). Это XML моего класса:

<class name="Project.Engine.Domain.User,Project.Engine" table="Users" lazy="true"> 
    <id name="UserID" column="UserID"> 
    <generator class="native" /> 
    </id> 
    <property name="Firstname" column="Firstname" type="string" not-null="true" 
    length="255" /> 
    <property name="Lastname" column="Lastname" type="string" not-null="true" 
    length="255" /> 
    <property name="Email" column="Email" type="string" not-null="true" 
    length="255" /> 
    <one-to-one name="Wish" cascade="all" property-ref="UserID" 
    class="Project.Engine.Domain.Wish, Project.Engine" /> 
</class> 

метод, чтобы получить все мои пользователи следующий:

public PagedList<User> GetAll(int pageIndex, int pageSize, 
    string orderBy, string orderByAscOrDesc) 
{ 
    using (ISession session = NHibernateHelper.OpenSession()) 
    { 
     var users = session.CreateCriteria(typeof(User)); 
     users.Add(Restrictions.IsNotNull("Wish")); 
     return users.PagedList<User>(session, pageIndex, pageSize); 
    } 
} 

Как вы можете заметить, я добавил ограничение на дочерний объект. Это не работает должным образом, так как метод возвращает всех пользователей, включая свойства Wish, как null. Любая помощь?

это XML для ребенка:

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"> 
    <class name="Project.Engine.Domain.Wish,Project.Engine" table="Wish" lazy="false"> 
    <id name="WishID" column="WishID"> 
     <generator class="native" /> 
    </id> 
    <property name="UserID" column="UserID" type="int" not-null="true" length="32" /> 
    <property name="ContentText" column="ContentText" type="string" not-null="false" length="500" /> 
    <property name="Views" column="Views" type="int" not-null="true" length="32" /> 
    <property name="DateEntry" column="DateEntry" type="datetime" not-null="true" /> 
    </class> 
</hibernate-mapping> 

Answer 1

Ну, есть ошибка с one-to-one и null Проверка стороны, которой может не быть. Я уже столкнулся с этим, но забыл об этом. property-ref просто визуализируйте его немного сложнее, чтобы диагностировать, но он существует и на фактическом one-to-one тоже.

Вот его соответствующий issue в инструменте отслеживания NHibernate.

Обход проблемы: испытание на null состояние недействительного имущества Wish, как Wish.Views.

Простите дикое предположение на тест синтаксиса, я не использую nhibernate-criteria больше уже много лет, но попробовать пример:

public PagedList<User> GetAll(int pageIndex, int pageSize, 
    string orderBy, string orderByAscOrDesc) 
{ 
    using (ISession session = NHibernateHelper.OpenSession()) 
    { 
     var users = session.CreateCriteria(typeof(User)); 
     users.Add(Restrictions.IsNotNull("Wish.Views")); 
     return users.PagedList<User>(session, pageIndex, pageSize); 
    } 
} 

Использование linq-to-nhibernate, я подтверждаю, этот способ работает со своими собственными проектами, что дает пример нет:

// The "TotalAmount != null" seems to never be able to come false from a 
// .Net run-time view, but converted to SQL, yes it can, if TransactionRecord 
// does not exist. 
// Beware, we may try "o.TransactionsRecord != null", but you would get struck 
// by https://nhibernate.jira.com/browse/NH-3117 bug. 
return q.Where(o => o.TransactionsRecord.TotalAmount != null); 

Я утверждаю, мой другой ответ, так как вы можете рассмотреть возможность использования many-to-one вместо этого, тем более, что вы не сделали Двунаправленное отображение (не соответствующие constrainedone-to-one в Wish) в дополнение к отсутствию фактического one-to-one. many-to-one не страдает от ошибки.

Answer 2

one-to-one картирование с использованием property-ref не является «фактический» один-к-одному, и, как правило, это признак many-to-one отображение должно использоваться вместо этого.
Возможно, это не связано с вашей проблемой, но вы можете попробовать.

«Фактический» взаимно однозначный имеет первичный ключ зависимой таблицы, равный первичному ключу родительской таблицы. (Зависимая таблица, Wish в вашем случае, будет иметь внешний первичный ключ, UserId в вашем случае. Смотрите это example.)

^{я когда-нибудь «играл» с «один-к-одно свойство-ссылка», и Я всегда заканчивал отказ от многих проблем. Я заменил это на более классические сопоставления, либо изменив свой db на наличие фактического взаимно однозначного, либо используя много-к-одному и живу с коллекцией на дочерней стороне, хотя он всегда будет содержать один элемент.}