Print Page | Close Window

Requery not matching Navigation properties as expected

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=2238
Printed Date: 30-May-2025 at 2:20pm


Topic: Requery not matching Navigation properties as expected
Posted By: midnit
Subject: Requery not matching Navigation properties as expected
Date Posted: 19-Oct-2010 at 10:08am

We have an EntityManager that contains Deals and a Deal has DealTrxs. If the client has cached a Deal that has 4 DealTrxs and then it gets notified that the Deal has been changed it requeries that single Deal with basically a full object graph defined in its query and we expect the Deal to fully represent the latest state of the Deal based on whats in the database.

What I seeing though, is that if the Deal has more DealTrxs it shows correctly, but if the Deal has lost DealTrxs then the current cache of the Deal continues to show however many DealTrxs it had to begin with.
 
1. So on my screen I have Deal with 4 DealTrxs
2. On your screen you delete 2 of the DealTrxs and save
3. My screen see's your change and requeries (DataSourceOnly) that Deal (with its graph), afterwhich it still shows 4 DealTrxs on my screen and in my EntityManager.
 
The database has the correct data but my EntityManager is showing me bad data. What am I missing to get this data properly synced? This also makes it so if I try to edit the Deal on my screen when I save the changes there is a concurrency error.
 



Replies:
Posted By: kimj
Date Posted: 20-Oct-2010 at 7:37pm
You're not missing anything, this is unfortunately a bug.  A process known as "ghosting", where cleanup of the "ghost" data is done, is not occurring here.  We've opened a very high priority bug report to get this fixed. 


Posted By: ken.nelson
Date Posted: 19-Nov-2010 at 7:20am
We've been dealing with this same issue for about a year and a half now, but we had just assumed this was how things were supposed to work regarding entity deletion and cached entities.  Our workaround was always to make a call to remove the 'child' entities from the entity manager before performing the requery.  Reading this, it sounds like this behavior wasn't intentional at all.  What's the status on this fix?  Once fixed, would the EntityState of the deleted "DealTrx" entities in cache be Detatched after the requery or would they simply no longer be in the cache?


Posted By: kimj
Date Posted: 19-Nov-2010 at 9:14am
Well ... it did turn out that the existing logic was intentional.   Ideally, DevForce would be able to detect the "ghost" entities during a requery and remove them from cache, but can't do so with related entities queried via an "Include".  Ken, the latest 6.0.7 EAP build you have contains fixes for all bugs found by midnit related to cache coherence and import/requerying, and you should stick with your workaround.



Print Page | Close Window