Is it worth to add plain List() methods other than Page?
djechelon opened this issue · 2 comments
The GetPagedList method is very useful at feeding paginated queries because it provides both with the items in the page and the total count of items. This requires two queries to be run.
In my personal experience, and specifically in Hibernate/Oracle, I have witnessed cases where this has a severe impact on performance up to being unusable.
In particular, there are situations in which getting the n-th page is cheap while getting the total count requires scanning millions of items.
To make it short, when I require only a sublist list of item, and not the count, I prefer not to run the SQL count.
I see that GetAll() method is deprecated. But that's the method I am currently using to build a query that won't resolve into a count.
Does it make sense to duplicate public PagedList<TElement> GetPagedList(...)
into public IList<TElement> GetList(...)
. Of course, I am already aware that eagerly loading a table full of records without limiting results is dangerous, but I take responsibility of controlling the max size, or to perform a controlled indefinite pagination.
Ideas? I could provide code for it. I am going to extend my repositories for that
public interface ISmallRepository<T> : IRepository<T> where T: class
{
IQueryable<T> All();
}
public abstract class SmallRepositoryBase<T> : Repository<T>, ISmallRepository<T> where T: class
{
public virtual IQueryable<T> All() => _dbSet.All();
....
}
you own the risk
Ok, looks like I had the official version which probably lacks most recent developments.
What I really wanted is the GetAll parameterized so that the filter can be null.
The classic GetAll
returns an IQueryable where I must make sure that the filter (generated dynamically) is not null before applying it.
I have made a change to add optional selector support. I'll post for discussion