I have an API set up in my project for a grid to call to get audit records to display to an admin. The grid has infinite scrolling set up and uses oData built into mvc4. So, it will make a call to the api with $top equal to the number of rows it is supposed to get and $skip set to get to the proper page.
Inside the API, I make this call to nhibernate to get an IQueryable to return for MVC4 to do it’s dark oData magic:
m_session.Query<AuditInfo>().FetchMany(x => x.Parameters).Fetch(x => x.AuditType).Fetch(x => x.Status)
In this, AuditInfo has a collection of parameters hanging off it, as well as lookup tables for the type and status.
My issue is that if I ask for 30 rows, it will return some number <= 30. I’ve been able to trace this a little bit, and the problem seems to be that nhibernate has the TOP and JOIN statements in the same query, so when an audit has more than one parameter on it, it creates a copy of the audit to hold the second parameter for returning it. Doing this takes up a space in the TOP(30) that the query allows for. Then, when it gets back to nhibernate, it appears that it merges these rows, leaving me with a collection that has less records than I wanted.
My question here is: How can I set this call up so I can get an accurate number of records without resorting to fetching the parameters separately and having n+1 queries?
basicly you can’t easyly because that is how sql works. leave out the FetchMany and it should work using Select N+1. To remedy that you can tweak the collection batch-size so NH will load more than one collection of the same type at once.