views:

392

answers:

3

Hi,

I've been stuck with this problem for over a week now. Hopefully some one can point me in the right direction.

I start with a brief description of my schema.

Asset 1--->1 Address *-->1 Area *-->1 Region *-->1 Country

Package 1-->* Asset

Using Self Tracking Entity (STE) + WCF.

Steps:

  1. Call data store for a list of assets.
  2. Call data store for a list of packages.
  3. User selects a package and assign some assets to it.
  4. Save package.

In step 2, the call uses eager loading of Addresses.

from p in context.Assets.Include("Address.Area.Region.Country")

This is the error when attempting to call

context.Packages.ApplyChanges(package)

AcceptChanges cannot continue because the object's key values conflict with another object in the ObjectStateManager. Make sure that the key values are unique before calling AcceptChanges.

EDIT

After snooping around, i found that this is a STE issue. The problem being you cannot persist a graph that contains multiple instances of the same entity as outlined here. Here is my question.

How can I add an entity to my entity collection. The new entity may have related entities that contain the same key as one already in the collection. I.e. Add a new asset that may contain the same address, area, region or country entity.

Here are my constrains:

  1. I must use the navigational collection because it affect the UI.
  2. I cannot pre-fetch all entities that will be involved because the data set is simply too large.
  3. I must be able to take snap-shots of the entity at anytime in order to keep a history and use it to "undo" any changes.

I am aware of the possible solutions suggested by Diego B Vega, but those are not options i can use for my solution. Has anyone any other ideas?

+1  A: 

Have you considered just giving up on ORM-s and going back to normal access, if you know what I mean :-)

Not kidding - by the time you wrestle with one single issue like that one (which smells like ORM bug more than anything else) you could have rolled out your own 5-10 functions to do normal sproc calls and easier data type conversion and then you are back to being in full control and and not stuck by libraries which are going to take another like 5yr to stabilize.

Especially since you seem to have very clean schema - meaning quite simple queries and straight forward updates.

ZXX
I really like the thought of that but unfortunately i don't have quite as much flexibility as that. I will put it into consideration in future project designs.
Tri Q
I just dismantled one, like 2 mo ago so it's from the personal experience :-) Nedded just one simple class to create/cleanup connection and excecue readers (it's DataReader 99% of the times anyway) and one static class to construct In/Out params on the fly (6-8 types) and convert nullable results (6-8 types again) with short functions (so I can type less :-) Oh and one smart template class to auto-dispose reader and connection. What a relief - not to mention perf boost :-)
ZXX
+1  A: 

I encountered the same issue and finally came up with a solution. The basic idea is to prevent certain navigational class type from attaching to the ObjectContext. Here is what I did:

  1. Modified the context.tt template to make SelfTrackingEntitiesContextExtensions class partial.
  2. Copy the 2 ApplyChanges functions to newly created Custom.Context.Extension.cs and rename them as CustomApplyChanges. Each will have one additional parameter as array of Type

public static void CustomApplyChanges(this ObjectContext context, string entitySetName, TEntity entity, Type[] excludeTypes) where TEntity : IObjectWithChangeTracker

  1. Add a condition to the for loop to exclude any class type contains in the excludeTypes array.

region Handle Initial Entity State

foreach (IObjectWithChangeTracker changedEntity in entityIndex.AllEntities.Where(x => x.ChangeTracker.State == ObjectState.Deleted && !excludeTypes.Contains(x.GetType()))) { HandleDeletedEntity(context, entityIndex, allRelationships, changedEntity); }

foreach (IObjectWithChangeTracker changedEntity in entityIndex.AllEntities.Where(x => x.ChangeTracker.State != ObjectState.Deleted && !excludeTypes.Contains(x.GetType()))) { HandleEntity(context, entityIndex, allRelationships, changedEntity); }

endregion

  1. The usage

Type[] excludeTypes = { typeof(Asset), typeof(Address), typeof(Region)};

rep.Entities.CustomApplyChanges(entity, excludeTypes); var changedEntry = rep.Context.ObjectStateManager.GetObjectStateEntries>(System.Data.EntityState.Added | System.Data.EntityState.Modified | System.Data.EntityState.Deleted); foreach (var e in changedEntry) { if (excludeTypes.Any(c => c == e.Entity.GetType())) { rep.Context.Detach(e.Entity); //detach unchanged objects } }

drchip.PL
+1  A: 

FYI, I wrote a blog post with some additional suggestions to what I had already responded in the EF Forums. Here is the blog post.

divega
This is a very useful blog. Just what i needed. The graph iterator is worth looking into.
Tri Q