Extra overloading Fetch methods using AsNoTracking()

[jersiovic]

What do you think of offering extra overloads for Fetch methods that use AsNoTracking in order to improve performance?

    public virtual IQueryable<T> FetchWithNoTracking(Expression<Func<T, bool>> predicate)
    {
        return Table.AsNoTracking().Where(predicate);
    }

Indeed in order to help devs to don't forget to use the most most optimal one I would use:

public virtual IQueryable<T> Fetch(Expression<Func<T, bool>> predicate)
        {
            return Table.AsNoTracking().Where(predicate);
        }

public virtual IQueryable<T> FetchWithTracking(Expression<Func<T, bool>> predicate) {
            return Table.Where(predicate);
        }

Problem is it is a breaking change, so to avoid unnoticed bad uses of the Fech method maybe it will be better to remove Fech method and only have FetchWithTracking and FetchWithNoTracking methods.

What do you think?

[Jetski5822]

Maybe we should have this by default, then on Flush it checks to see if the items are attached and reattach then if dirty save changes? Does the DbContext have an even for that?

[jersiovic]

Problem I see with this solution is we would spend extra processing time doing dirty checking just because we don't want to bother consumer code forcing it to ask us if the data it is going to consume is read only or not.
Read only queries are the most common ones so to avoid a lot of extra work we should avoid dirty checking for data related with those queries. The point is that who knows if a query needs tracking or not is the code who asks the query and consumes its data. So why don't let this code take the decision (it is easy to do it at this level)? In this way we avoid to lose processing time making a trick in repository to don't delegate the decision on who should take it.

[Jetski5822]

This is abstracted to the individual ContentStore. The content store implementation will dictate is a object is tracked or not, not the calling layer.