Eager loading caching bug?

Business.Employee user = new LA.POS.Business.Employee(); Business.Employee user2 = new LA.POS.Business.Employee(); 1. Data.Employee employee1 = user.Get(1); 2. Data.Employee employee2 = user2.Get(1); 3. IEnumerable access1 = employee1.EmployeeAccesses; 4. IEnumerable access2 = employee2.EmployeeAccesses; ========================================================================== (1.) [Loading the employee, and their access, this is what I'd expect as I'v turned on eager leading for employeeAccess] SELECT Employee.Id, Employee.EMail, Employee.EmployeeName, Employee.IsAdministrator, Employee.LoginCode, Employee.Password, Employee.PreferredBaseColor, Employee.PreferredColor FROM Employee WHERE Employee.Id = 1; SELECT EmployeeAccess.Id, EmployeeAccess.ActionID, EmployeeAccess.EmployeeId, EmployeeAccess.HasAccess FROM EmployeeAccess WHERE EmployeeAccess.EmployeeId = 1 --> Time: 2 ms 'LAPos.vshost.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_32\System.Transactions\2.0.0.0__b77a5c561934e089\System.Transactions.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. 'LAPos.vshost.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_32\System.EnterpriseServices\2.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Setting entity into cache [Employee [Id=1, EntityState=New]] Setting entity into cache [EmployeeAccess [Id=100, EntityState=New]] Setting entity into cache [EmployeeAccess [Id=101, EntityState=New]] Setting entity into cache [EmployeeAccess [Id=102, EntityState=New]] Setting entity into cache [EmployeeAccess [Id=103, EntityState=New]] Setting entity into cache [EmployeeAccess [Id=104, EntityState=New]] (2.) [this is what I'd expect as the enity has the Cached atribute] Found entity in cache [Employee [Id=1, EntityState=Default]] (3.) [entities retrieved from SQL again, and put into the cache again, this is not correct] SELECT EmployeeAccess.Id, EmployeeAccess.ActionID, EmployeeAccess.EmployeeId, EmployeeAccess.HasAccess FROM EmployeeAccess WHERE EmployeeAccess.EmployeeId = 1 --> Time: 1 ms Setting entity into cache [EmployeeAccess [Id=100, EntityState=New]] Setting entity into cache [EmployeeAccess [Id=101, EntityState=New]] Setting entity into cache [EmployeeAccess [Id=102, EntityState=New]] Setting entity into cache [EmployeeAccess [Id=103, EntityState=New]] Setting entity into cache [EmployeeAccess [Id=104, EntityState=New]] (4.) [Nothing happens, I presume the entries were found in the Cache?, so this looks correct]

Hi,

Could you possibly reformat your question as it's kind of hard to make out :-)

Cheers,

Andrew.

Hi Anthony,

This is currently a limitation in our caching in that we don't support what's called "Query Caching".

Step 4 doesn't hit the database because the collection is loaded in step 3.

Cheers,

Andrew.

Ok,

I was intending to use eager loading to retrieve all related data in a single entity in a single call for efficiency.

I reference the data by using the sub-collections, "Query caching" is not currently supported in Lightspeed. To obtain this performance increase I want, should I continue using the example code above, and the functionality will be made availible in the future, or is there another way to achieve what I would like to do, or should I not use eager-loading?

Cheers

Anthony

Hi Anthony,
[quote user="antprog"]I was intending to use eager loading to retrieve all related data in a single entity in a single call for efficiency. [/quote]
You don't need to use the second-level cache for this. Just use normal eager loading and the first time you request a parent entity, the child collection will be loaded too. Within a single Unit of Work an entity is only ever loaded once.

The second level cache (using CachedAttribute) is about caching accross multiple units of work - possibly accross Process/Thread boundaries. E.g. A readonly list of country reference data is shared accross all requests in a web app.

Hope this helps,

Andrew.