I have an EntityManager in a Singleton. For some reason, one of my queries won’t use the client side cache.  Whenever I use SQL Profiler, I keep seeing the following query:

SELECT TOP (1)

[Extent1].[ID] AS [ID],

[Extent1].[CompanyID] AS [CompanyID],

[Extent1].[Description] AS [Description]

FROM  [dbo].[tblGLAccountTypes] AS [Extent1]

INNER JOIN [dbo].[tblPvxCompanies] AS [Extent2] ON [Extent1].[CompanyID] = [Extent2].[ID]

WHERE (1 = [Extent2].[Organization]) AND (9 = [Extent1].[ID])

Stepping through the code, I can see exactly when it is being called.  It’s being called on the last line of the following code:

Public Overrides Sub LoadRecord(ByVal em As EntityManager, ByVal ID As Long)

        Dim emg As EntityManager_GL = DirectCast(em, EntityManager_GL)

        Dim item = (From queryItem In emg.efGLAccountTypes

              Where queryItem.ID = ID

              Select queryItem).FirstOrNullEntity

My original theory was that it was because of the DirectCast, but I’ve got other code that does the same casting and seems to work.  My other theory is I have setup a FilterQuery setup in my BOS code like this:

        Protected Overrides Function FilterQuery() As Boolean

            QueryFilters.AddFilter(Of DomainModel.emGL.efGLAccountType)(Function(q) q.Where(Function(c) c.efPvxCompany.efOrganization.ID = organzationId))

            Return MyBase.FilterQuery()

        End Function                                               

Does adding a filterquery negate the client side cache?  Is there a way to change that?  I sort of assume the logic would be, if you retrieved the value in the past, the value should still be cached.

 

When you execute a query, it will hit the datasource unless you have explicitly set QueryStrategy.CacheOnly or this exact same query is already in the QueryCache. (i.e. was executed before)

The above will happen even if the entity you are looking for is already in the EntityCache.

 

If you are actually querying by key, (i.e. myKey.ToKeyQuery().With(EntityManager_GL ).FirstOrNullEntity(); ) then it will first look for for the entity in the EntityCache and only look for it in the datasource if it is not in cache.

 

I couldn't verify the impact of having or not a filter in the query interceptor. Could you provide a sample reproducing the issue?

 

You can find more about about http://drc.ideablade.com/xwiki/bin/view/Documentation/query-cache#HQueryCache - QueryCache , http://drc.ideablade.com/xwiki/bin/view/Documentation/start-entity-cache - EntityCache , and http://drc.ideablade.com/xwiki/bin/view/Documentation/query-strategy - QueryStrategy in the http://drc.ideablade.com/xwiki/bin/view/Documentation/ - DevForce Resource Center .

 

Regards,

   Silvio.

The DefaultQueryStrategy uses a Optimized FetchStrategy. Per the http://drc.ideablade.com/xwiki/bin/view/Documentation/query-fetchstrategy#HFetchStrategies - DRC :

 

 

So, in fact a query would only skip the trip to the datasource if the query is in the QueryCache.

What operations are performed between these queries? The reason I ask is that removing an entity from an EntityManager will clear the entire QueryCache and re-executing a query will hit the datasource again. Also, you can always check if the query is actually in the QueryCache:

 

I've tried the snippet you provided earlier, but I couldn't verify the behavior. In my setting, a query will never hit the datasource if it's in the QueryCache; regardless of having or not a filter in the interceptor.

Since there might be another detail that is different between my setting and yours, a sample solution (preferably against NorthwindIB) would help a great deal in trying to determine the issue.

 

Regards,

Silvio.

 

Looking deeper in your snippet we realized that because you are using 'Select queryItem' after the where clause the result is considered a projection and the query will not be placed in the QueryCache:

 

 

 

Eliminating the 'Select' from the query will resolve the issue and not affect the result:

 

 

That will resolve the issue about the query hitting the datasource everytime.

 

Regards,

   Silvio.