Fix. Very important. Speed improvement.

Thanks Vipal for your reply.

1- I believe the lazy loading is not well described by microsoft. By its definition, i agree with you that when disabled all related entities are filled when you load a specific entity but in practice its not the case. If you request to get data from single entity with no join query, related entities are not filled up. Related entities are filled up only when you use the .Include() in your query. Therefore, disabling lazy loading is a performance improvement on EF queries and not a bad thing.

2- Why in nop, we are disabling autotracking only when calling stored procedures ? Why not doing the same for dbContext Insert() operation ?

Thanks in advance for your clarification.

houssam.hamdan wrote:

I agree with your point #1 its little bit confusing.

for point #2 we can disable the autotracking only when we are retriving the data only for readonly operation.

i mean after fetching the entities we are not going to update or delete the entities.

and we did it on storage procedure as we are calling SP for get all product for read only purposes.

and when we retrieve the data from SP those entities is not attached with DB context.

so before attaching those entities to DB context they have disabled the tracking for performance improvement as we are fetching products only for listing purpose either on front end or on back end

so we can not disable autotracking on insert time as that time tracking should be enabled to know EF that Entity is inserted or modified or deleted etc.

You are right, we cannot disable autotracking for insert, update and delete. On the other side, for read only operation. The below code is copy pasted from nop source code.

public IList<TEntity> ExecuteStoredProcedureList<TEntity>(string commandText, params object[] parameters) where TEntity : BaseEntity, new()
        {
            //add parameters to command
           // code removed for clarity


            var result = this.Database.SqlQuery<TEntity>(commandText, parameters).ToList();

            //code added to stop autotracking here
            bool acd = this.Configuration.AutoDetectChangesEnabled;
            try
            {
                this.Configuration.AutoDetectChangesEnabled = false;

                for (int i = 0; i < result.Count; i++)
                    result[i] = AttachEntityToContext(result[i]);
            }
            finally
            {
                this.Configuration.AutoDetectChangesEnabled = acd;
            }
            //end of autotracking code here

            return result;
        }

Please explain to me what is the difference in performance if i stop the autotracking code snippet above especially since the result object is always filled with data using this.database.sqlquery(). The data is already there, why do i need to attach it again? why cant i return it directly ?

I am sure there is something i did not understand yet and you will help me on that.

i think you got a thinkable points.

if we are getting records only for readonly purpose then may be we don't need to attach entity to DBContext and disabled autotracking.

and we can directly return the records without attaching entities to DB context.


I have the same question now that why we need to attach the entity to DBContext as we are already return them for readonly purpose ??

i know that if we need to modify the retrieved records then we need to attach entity to DbContext for tracking purpose as we get entity from SP so we need to attach it to DBContext but we are attaching the entity with autotracking off so it means we are attaching only for readonly purpose and that doesn't make sense to me.


is anybody in this forums has any known reason for it ??