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...