DevForce Community Forum : Query Cache and Primary Key Queries

Query Cache and Primary Key Queries : Ok Greg, thanks for looking into...

Mon, 26 Jul 2010 14:17:42 -700

Author: kosgia
Subject: 1927
Posted: 26-Jul-2010 at 2:17pm

Ok Greg, thanks for looking into this.

Query Cache and Primary Key Queries : Originally posted by kosgiaShouldn't...

Mon, 26 Jul 2010 12:25:54 -700

Author: GregD
Subject: 1927
Posted: 26-Jul-2010 at 12:25pm

Originally posted by kosgia

Shouldn't the second query be executed and served�from the cashe?

Returning to your original questions:

Apparently the cited rules about unrestricted queries, which do apply to DevForce Classic, do not currently apply in either DevForce 2009 or 2010. They were originally implemented in support of something called enumeration entities in DevForce Classic. Without going into boring detail about those, it suffices to say that they were used with data that seldom changed, and that the benefit of the rules you cited emerges most clearly in the case of such (highly static) data.

So, the docs are wrong: in DevForce 2009, if DevForce hasn't seen a specific query before, it will go to the datasource under the default query strategy.

Query Cache and Primary Key Queries : Originally posted by kosgia<P...

Mon, 26 Jul 2010 12:12:49 -700

Author: GregD
Subject: 1927
Posted: 26-Jul-2010 at 12:12pm

Originally posted by kosgia

Greg, I am actually working on windows forms and synchronous queries, so my scenario included only these environment settings.

Yes, it seems that we reorganized the forums a while back so that Silverlight development isn't separated from WinClient development and I'm just finding out about it. Used to be that if the forum title said "Silverlight", it was only for Silverlight questions, but no more. So you posted in the correct forum.

Query Cache and Primary Key Queries : Greg, I am actually working on...

Sat, 24 Jul 2010 04:24:39 -700

Author: kosgia
Subject: 1927
Posted: 24-Jul-2010 at 4:24am

Greg, I am actually working on windows forms and synchronous queries, so my scenario included only these environment settings. Thanks for taking the time to duplicate it also with Silverlight and asynchronous queries.

Query Cache and Primary Key Queries : You've posted in the Silverlight...

Fri, 23 Jul 2010 12:16:46 -700

Author: GregD
Subject: 1927
Posted: 23-Jul-2010 at 12:16pm

You've posted in the Silverlight forum, but your examples are of synchronous queries. Are you really working in Silverlight?

Originally posted by kosgia

Shouldn't the second query be executed and served�from the cashe?

I thought so, but I duplicated your scenario (in Silverlight, using asynchronous queries) and also see the two queries. I'll check into it with the Development team.

Query Cache and Primary Key Queries : That's okDavid, thanks.

Fri, 23 Jul 2010 10:52:36 -700

Author: kosgia
Subject: 1927
Posted: 23-Jul-2010 at 10:52am

That's ok David, thanks.

Query Cache and Primary Key Queries : On June 29, you opened two topics...

Fri, 23 Jul 2010 10:33:46 -700

Author: davidklitzke
Subject: 1927
Posted: 23-Jul-2010 at 10:33am

On June 29, you opened two topics on the Forum. One was on "Querying only the Cache" (which we have answered). The other topic is this one on "Query Cache and Primary Key Queries". Instead of opening two support tickets, we only opened a support ticket for "Quering only the Cache". Thank you for bringing this to our attention. We will open a support ticket for "Query Cache and Primary Key Queries".

Query Cache and Primary Key Queries : Almost one month has passsed since...

Fri, 23 Jul 2010 01:50:34 -700

Author: kosgia
Subject: 1927
Posted: 23-Jul-2010 at 1:50am

Almost one month has passsed since my initial post. An Ideablade employee response (or from anybody else) would really be appreciated.

Edited by kosgia - 23-Jul-2010 at 1:51am

Query Cache and Primary Key Queries : Hi, I am using DevForce 5.2.6.0. The...

Tue, 29 Jun 2010 08:39:46 -700

Author: kosgia
Subject: 1927
Posted: 29-Jun-2010 at 8:39am

Hi,

I am using DevForce 5.2.6.0.

The folowing is from the product manual for DevForce 2009.

Query Cache

When a EntityManager begins to process a normal query, it checks its query cache to see if it has processed this exact query before. If the EntityManager finds the query in the query cache, it assumes that the objects which satisfy the query are in the entity cache; accordingly, it satisfies the query entirely from the cache without consulting the data source. A one-to-many entity navigation, such as from employee to the employee‟s orders, is translated implicitly to an entity query language (OQL) query that also enters the query cache. The next time the application navigates from that same employee to its orders, the EntityManager will recognize that it has performed the query before and look only in the cache for those orders. The query cache grows during the course of a session. Certain operations clear it as one of their side-effects; removing an entity from the cache is one such operation. The developer can also clear the query cache explicitly. We just said that the EntityManager searches the query cache for an exact match of the current query, but that was really a �little white first approximation.� Actually, the EntityManager does better than that: it searches either for an exact match, or for an unrestricted query returning the same type. If, for example, you have previously retrieved �all Customers� and now ask for �Customers from Canada�, your new query will be satisfied from the cache.

Primary key queries

A query for business objects by primary key may be resolved entirely in the cache. If we search33 for the employee with Id = �1‟ the EntityManager will try to find it in the cache and, if not found there, will only then look for it in the data source. The EntityManager treats navigation along a one-to-one relationship, such as from Employee to HomeAddress, as a primary key query. Navigation in the parent direction along a one-to-many relationship, such as from an OrderDetail to its parent Order, is also a primary key query.

The default QueryStrategy i use is Normal which, if i am not mistaken, uses an Optimized FetchStrategy, meaning that the EntityManager will try to satisfy queries from the cash first and then from the DataSource as long as it finds them in Query Cashe.

I have a business objecr A.

After executing the following code:

DomainModelEntityManager.DefaultManager.A.Execute();

DomainModelEntityManager.DefaultManager.A.Where(f => f.Id == MyId).Execute();

and having the trace viewer and sql profiler open i can see that 2 queries are executed on database, one for each command.

Question 1:

Shouldn't the second query be executed and served from the cashe?

The first query is an unrestricted query returning objects of type A. An exact match for the second query does not exist on query cashe but an unrestricted query returning the same type (A) exists (First Query), so according to the product manual the second should be served from the cash.

Question 2:

I know that A.Id is the primary key for business objects of type A. Does the EntityManager consider the second query to be a Primary Key query? According to the manual "If we search for the employee with Id = �1‟ the EntityManager will try to find it in the cache and, if not found there, will only then look for it in the data source." it should but, please correct me if i am mistaken, it does not. Does the EntityManager consider as primary key queries only navigation queries or can it distinguish when a user searches only by primary key using the Where(Expression<Funcbool>> predicate) method. What if a business object has a complex primary key?

To make sure that i use the correct query strategy i also tried writing the above commands as:

DomainModelEntityManager.DefaultManager.A

.With(new QueryStrategy(FetchStrategy.Optimized, MergeStrategy.PreserveChanges, QueryInversionMode.On))

.Execute();

DomainModelEntityManager.DefaultManager.A

.Where(f => f.Id == MyId)

.With(new QueryStrategy(FetchStrategy.Optimized, MergeStrategy.PreserveChanges, QueryInversionMode.On))

.Execute();

Thank you in advance,

Kostas.