It took me all day, but I found a workaround for what I think might be a bug in the criteria implementation. It doesn't seem to me that by creating an alias for a criteria, I should be limiting my result set, but that is what was happening.

Here is what was troubling me:
ICriteria crit = session.CreateCriteria(typeof(Core.Domain.Property), "prop");
//this, and other .SetFetchMode variations, wouldn't work
//crit.CreateAlias("_Sponsor", "spon").SetFetchMode("spon", FetchMode.Join);

//this finally worked
crit.CreateCriteria("_Sponsor", "spon", NHibernate.SqlCommand.JoinType.LeftOuterJoin);

crit.Add(Expression
.Or(
Expression.InsensitiveLike("spon._Title", find),
Expression.InsensitiveLike("_PropertyName", find)
)
);

crit.List(); //(actually done later, but you get the idea)


Originally I was doing the CreateAlias to make an alias "spon" so I could sort/search by values in the related sponsor class. However I realized that my list of Property objects was missing any Property which didn't have an associated sponsor, and I couldn't have that. I tried CreateAlias along with every permutation of .SetFetchMode I could think of (session.CreateCriteria(...).SetFetchMode, crit.SetFetchMode, etc.) and NHibernate always joined the aliased class with an inner join, instead of the left outer join I needed so that I didn't lose Properties without sponsors.

I thought, based on http://www.hibernate.org/hib_docs/refer ... teria.html #12.5 in the docs, that I could specify the type of join for my alias with SetFetchMode.

Perhaps I was way off base in thinking that was the way to do it, but I eventually discovered the 3-parameter CreateCriteria which let me specify the join type of my alias, and now I can search and sort on my related objects without losing the objects that don't have those relationships. It only took me 5 hours...

According to the API docs, your call to createAlias

"Functionally equivalent to Criteria.createAlias(String, String, int) using CriteriaSpecification.INNER_JOIN for the joinType."

Calling createAlias and setFetchMode on the same property doesn't make sense. After the createAlias, you have already done the join. I'm not sure how hibernate handles this, but I wouldn't be surprised if you end up with two joins in the query.

What you ended up doing is functionally equivalent to what you were attempting with createAlias and setFetchMode.