Hi Mag -
You are correct. And no, it's not faulty code. RemovedEntitiesTracker is not intended to represent entities that should be removed from the database, although - as you point out - you can use it that way.
What you should do is check each entity within the RemovedEntitiesTracker for the .IsNew flag. If it's new - it obviously doesn't need to be deleted.
Realize - sometimes you will want to remove an entity from a collection and DO NOT want it deleted from the database. So, in your paradigm here - you will need to remove that entity from both the EntityCollection and the RemovedEntitiesTracker.
Like you, I once used the RemovedEntitiesTracker as a bucket for entities to be deleted. You can do this, and it's a good solution if you are careful. However, we no longer use it for this purpose.
Problem 1: RemovedEntitiesTrackers are not serialized by default, so if you serialize (ie, you clone the graph or pass through a remoting boundary) - you will loose all those entities. To add RemovedEntitiesTracker to serialization, you will need to manually override GetObjectData() and OnDeserialized() and add it to SerializationInfo.
Problem 2: Another problem is you can accidentally cut RemovedEntitiesTrackers off from the graph entirely, thus loosing all the entities you marked for delete. For example, if you have an entity graph A-B:C. Where A has a parent B. B has an entity collection C. If you remove an entity from collection C, it will be happily marked for delete in C's RemovedEntitiesTracker. Enter the problem: Say entity A switches from parent B to parent B2. Whoops! B & C are no longer in the graph - you just lost your RemovedEntitiesTracker. Not a robust tracking solution.
Instead, we now have an EntityGraph class that has an EntitiesMarkedForDelete collection.
Hope this helps! Best of luck...
Ryan
