Both RavenDb and CouchDB have better ways to do pagination than querying to get the count first as 1 query and then a separate query for the results for the specific page you are on.
In CouchDb you can get the total_rows from the results to the specific query and therefore could skip the call to Count() as a separate query first.
In RavenDb they have a .Statistics(out stats) call that you can add to return the TotalResults when you make the query call and therefore can skip the call to Count() first as well. (http://ravendb.net/docs/client-api/querying/paging)
The problem is that our PagingOptions are generic and know nothing about the repository they are being used against so the logic in it is very generic.
I'm just wondering if there is a good way to get the specific logic for a repository in there so we can take advantage of what they have to offer.
Both RavenDb and CouchDB have better ways to do pagination than querying to get the count first as 1 query and then a separate query for the results for the specific page you are on.
In CouchDb you can get the total_rows from the results to the specific query and therefore could skip the call to Count() as a separate query first.
In RavenDb they have a .Statistics(out stats) call that you can add to return the TotalResults when you make the query call and therefore can skip the call to Count() first as well. (http://ravendb.net/docs/client-api/querying/paging)
The problem is that our PagingOptions are generic and know nothing about the repository they are being used against so the logic in it is very generic.
I'm just wondering if there is a good way to get the specific logic for a repository in there so we can take advantage of what they have to offer.