Accepted answer

this was a bug in nhibernate. it would try to get the class mapping data for the enumerable type parameter. when projecting an enumerable of a mapped class this works perfectly. in this instance, however, the enumerable type parameter is string. string does not have a class map and so it was substituting a null constant in the query which then caused issues later on.

to further illustrate this, the sql query for this example would be:

select,, from post p left join category c on = c.postid where = 1

this would return data like so: |   | 
 cat 1  | 1      | post a
 cat 2  | 1      | post a

nhibernate would then, in memory, perform a group by operation, including null checks, to create a list of categories for each unique value of the group by operation is performed using column indexes.

that is what should be happening. the bug was causing the results to be transformed, before the group by operation, into:

 null   | cat 1  | 1      | post a
 null   | cat 2  | 1      | post a

nhibernate was then filtering results where column 0 was null, meaning none of them survive.

the pull request containing the fix is here:


you can create categorymap, category entity and change to:

public virtual ilist<category> categories { get; protected set; }

i'm presuming is a linq to nhibernate querying limitation.


try changing

var second = session.query<post>()
    .where(x => == 1)
    .select(x => new {

to tolist().single() instead of single().

i've seen this issue before, the problem is that the query will return multiple rows that are then coerced into a single anonymous type. the query fails because the intermediate results contain multiple rows instead of a single row.

Related Query

More Query from same tag