arch/UnitOfWork

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