Jeżeli Ilość były ciągiem, to byłoby proste:
.Add(Restrictions.Like("Number", "some_value",MatchMode.Anywhere))
Skoro masz numer, NHibernate sprawdzi typ numeru, a jeśli dać mu ciąg będzie rzucać wyjątek.
Nie wiem, dlaczego zespół NH nie przewiduje przeciążenie z obiektu jako parametr i parametrach MatchMode ....
Tak czy inaczej, nadal można to zrobić tak:
.Add(Expression.Sql("{alias}.Number like ?", "%2%", NHibernateUtil.String))
edytować
O alias:
(nie mogę znaleźć gdzie dokumentacja mówi o tym ale tu m y rozumienie tego)
{alias} zwraca alias używany wewnątrz przez NH dla najnowszej CreateCriteria. Więc jeśli miałeś:
session.CreateCriteria<User>("firstAlias")
.CreateCriteria("firstAlias.Document", "doc")
.Add(Expression.Sql("{alias}.Number like ?", "%2%",
NHibernateUtil.String)).List<User>();
{alias} w tym przypadku byłby "doc" - więc skończyłbyś z: doc.Number.
Zawsze używaj {alias} po parametrze CreateCriteria, którego aliasu musisz użyć.
świetnie, dziękuję. dla aliasu na wyrażeniu sql ... użyłem "this_.Number" czy to ok, czy mam gwarancję, że NHibernate będzie zawsze używał this_.? –
ponieważ zrobiłem alias moje kryteria z "wi" - session.CreateCriteria ("wi") - ale nie mogę użyć "wi.Number" w wyrażeniu sql, ponieważ dosłownie umieszcza je w T-SQL (jeśli to ma sens). –
i sens "wi" w regularnych wywołań tworzenia kryteriów jest w rzeczywistości konwertowany na "this_" w T-SQL wysłanym na serwer i poszedł dalej i umieścił alias w wyrażeniu sql na "this_.Number" –