Почему Fetch должен быть последним предложением в запросе Linq Nhibernate

Fetch должен быть последним предложением в Linq, судя по сообщению в блоге Майка Хэдлоу< /а>:

Обратите внимание, что если вы хотите смешать Fetch с другими предложениями, Fetch всегда должен стоять последним.

Итак, если Fetch просто указывает стратегию выборки для свойства, почему я не могу иметь больше предложений после Fetch? ЧАС

Один случай, с которым я сталкиваюсь, — это использование AsPagination (MVCContrib) с Fetch. Поскольку AsPagination пытается получить количество запросов с Fetch, добавляя .Count() в конец.

Итак, еще раз, почему стратегия извлечения свойства должна быть последним предложением в операторе запроса Linq Nhibernate?


fetch pagination linq nhibernate mvccontrib
person kaptan    schedule 28.12.2010    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Я столкнулся с той же проблемой, прежде чем понял, что происходит. http://groups.google.com/group/nhibernate-development/browse_thread/thread/b44957841c9416ba

Наиболее вероятная причина в том, что этот способ было проще реализовать, потому что нет необходимости учитывать возможные преобразования (выбрать/группировать по), которые могут произойти в запросе.

NHibernate всегда был сложным с точки зрения создания запросов на подкачку, когда у ваших сущностей есть связанные коллекции. Если вы используете Criteria или QueryOver, правильный способ сделать это — сделать так, чтобы запрос на подкачку возвращал только идентификаторы сущностей с проекцией Distinct. Эти идентификаторы будут использоваться в условии where подзапроса, который будет содержать все соединения.

Вы можете увидеть пример здесь (ответ):

Критерии пейджинга NHibernate с активным fetchmode. (с использованием беглого NH)

Я еще не пробовал эту технику в Nhibernate LINQ, но она может сработать.

person Dmitry S.    schedule 28.12.2010