I am using Entity Framework 4.3.1 in a project, using code first and the DbContext API. My app is an n-tier app where disconnected objects may come in from a client. I am using SQL Server 2008 R2 but will be moving to SQL Azure soon. I am running into an issue I just can't seem to solve.
Imagine I have a few classes:
class A {
// Random stuff here
}
class B {
// Random stuff here
public A MyA { get; set; }
}
class C {
// Random stuff here
public A MyA { get; set; }
}
By default, EF operates on object graphs. For instance, if I have an instance of B that encapsulates an instance of A and I call myDbSet.Add(myB);, it will also mark the instance of A as being added (assuming it is not yet being tracked).
I have a scenario in my app where I need to be explicit about which objects get persisted to the database, rather than have it track entire object graphs. The order of operations is as follows:
A myA = new A(); // Represents something already in DB that doesn't need to be udpated.
C myC = new C() { // Represents something already in DB that DOES need to be updated.
A = myA;
}
B myB0 = new B() { // Not yet in DB.
A = myA;
}
B myB1 = new B() { // Not yet in DB.
A = myA;
}
myDbSetC.Attach(myC);
context.Entry(myC).State = Modified;
myDbSetB.Add(myB0); // Tries to track myA with a state of Added
myDbSetB.Add(myB1);
context.SaveChanges();
At this point I get an error saying 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. I believe this happens because calling add on myB0 marks the instance of A as being Added, which conflicts with the instance of A already being tracked.
Ideally I could do something like call myDbSet.AddOnly(myB), but obviously we don't have that option.
I have tried several workarounds:
Attempt #1:
First, I tried creating a helper method to prevent myA from being added a second time.
private void MarkGraphAsUnchanged<TEntity>(TEntity entity) where TEntity : class {
DbEntityEntry entryForThis = this.context.Entry<TEntity>(entity);
IEnumerable<DbEntityEntry> entriesItWantsToChange = this.context.ChangeTracker.Entries().Distinct();
foreach (DbEntityEntry entry in entriesItWantsToChange) {
if (!entryForThis.Equals(entry)) {
entry.State = System.Data.EntityState.Unchanged;
}
}
}
...
myDbSetB.Add(myB0);
MarkGraphAsUnchanged(myB0);
While this solves the problem of it trying to add myA, it still causes key violations within the ObjectStateManager.
Attempt #2:
I tried doing the same as above, but setting the state to Detached instead of Unchanged. This works for saving, but it insists on setting myB0.A = null, which has other adverse effects in my code.
Attempt #3:
I used a TransactionScope around my the entire DbContext. However, even when calling SaveChanges() between each Attach() and Add(), the change tracker does not flush its tracked entries so I have the same problem as in attempt #1.
Attempt #4:
I continued with the TransactionScope, except I used a repository/DAO pattern and internally create a new DbContext and call SaveChanges() for each distinct operation I do. In this case, I got an error 'Store update, insert, or delete statement affected an unexpected number of rows.' When using the SQL Profiler, I find that when calling SaveChanges() on the second operation I did (the first Add()), it actually sends the UPDATE SQL to the database from the first operation a second time -- but doesn't change any rows. This feels like a bug in Entity Framework to me.
Attempt #5:
Instead of using the TransactionScope, I decided to use use a DbTransaction only. I still create multiple contexts but pass a pre-built EntityConnection to each new context as it's created (by caching and manually opening the EntityConnection built by the first context). However, when I do this, the second context runs an initializer I have defined, even though it would have already run when the app first started up. In a dev environment I have this seeding some test data, and it actually times out wating for a database lock on a table my first Attach() modified (but is still locked due to the transaction still being open).
Help!! I've tried about everything I can think of, and short of completely refactoring my app to not use navigation properties or using manually constructed DAOs to do INSERT, UPDATE, and DELETE statements, I'm at a loss. It seems there must be a way to get the benefits of Entity Framework for O/R mapping but still manually controlling operations within a transaction!
There must be something else you are not showing because there is no problem with the way how you attach and add entities. The following code will attach myA, myC, myB0 and myB1 to context as unchanged and set state of myC to modified.
myDbSetC.Attach(myC);
context.Entry(myC).State = Modified;
the following code will correctly detect that all entities are already attached and instead of throwing exception (as it would do in ObjectContext API) or inserting all entities again (as you expect) it would just change myB0 and myB1 to added state:
myDbSetB.Add(myB0);
myDbSetB.Add(myB1);
If your myA and myC are correctly initialized with keys of existing entities whole code will correctly execute and save except the single problem:
C myC = new C() {
A = myA;
}
This looks like independent association and independent association has its own state but API to set its state is not available in DbContext API. If this is a new relation you want to save it will not be saved because it is still tracked as unchanged. You must either use foreign key association or you must convert your context to ObjectContext:
ObjectContext objectContext = ((IObjectContextAdapter)dbContext).ObjectContext;
and use ObjectStateManager to change state of the relation.
As Ladislav suggested, I got the object instances consistent, which solved the problem of it trying to add redundant As.
As it turns out, both B0 and B1 actually encapsulate other objects (D0 and D1, respectively) which in turn encapsulate A. Both D0 and D1 were already in the database but not being tracked by Entity.
Adding B0/B1 caused D0/D1 to also be inserted, erroneously. I ended up using the object context API Ladislav suggested to both mark the ObjectStateEntry for D0/D1 to Unchanged, and the relationships between D0/D1 and A as Unchanged. This seems to do what I need: update C and insert B0/B1 only.
Below is my code to do this, which I call right before SaveChanges. Note that I'm sure there are still some edge cases that are not handled, and this is not throughly tested -- but it should give a rough idea what needs to be done.
// Entries are put in here when they are explicitly added, modified, or deleted.
private ISet<DbEntityEntry> trackedEntries = new HashSet<DbEntityEntry>();
private void MarkGraphAsUnchanged()
{
IEnumerable<DbEntityEntry> entriesItWantsToChange = this.context.ChangeTracker.Entries().Distinct();
foreach (DbEntityEntry entry in entriesItWantsToChange)
{
if (!this.trackedEntries.Contains(entry))
{
entry.State = System.Data.EntityState.Unchanged;
}
}
IEnumerable<ObjectStateEntry> allEntries =
this.context.ObjectContext.ObjectStateManager.GetObjectStateEntries(EntityState.Added)
.Union(this.context.ObjectContext.ObjectStateManager.GetObjectStateEntries(EntityState.Deleted))
.Union(this.context.ObjectContext.ObjectStateManager.GetObjectStateEntries(EntityState.Modified));
foreach (ObjectStateEntry entry in allEntries)
{
if (entry.IsRelationship)
{
/* We can't mark relationships are being unchanged if we are truly adding or deleting the entity.
* To determine this, we need to first lookup the entity keys, then state entries themselves.
*/
EntityKey key1 = null;
EntityKey key2 = null;
if (entry.State == EntityState.Deleted)
{
key1 = (EntityKey)entry.OriginalValues[0];
key2 = (EntityKey)entry.OriginalValues[1];
}
else if (entry.State == EntityState.Added)
{
key1 = (EntityKey)entry.CurrentValues[0];
key2 = (EntityKey)entry.CurrentValues[1];
}
ObjectStateEntry entry1 = this.context.ObjectContext.ObjectStateManager.GetObjectStateEntry(key1);
ObjectStateEntry entry2 = this.context.ObjectContext.ObjectStateManager.GetObjectStateEntry(key2);
if ((entry1.State != EntityState.Added) && (entry1.State != EntityState.Deleted) && (entry2.State != EntityState.Added) && (entry2.State != EntityState.Deleted))
{
entry.ChangeState(EntityState.Unchanged);
}
}
}
}
Whew!!! The basic pattern is:
Explicitly track changes as they are made.
Go back and clean up all the things Entity thinks it needs to do, but doesn't really.
Actually save the changes out to the DB.
This having to "go back and clean up" method is obviously sub-optimal, but it seems to be the best option for the moment, without having to manually attach peripheral entities (such as D0/D1) before I attempt any save operation. Having all this logic in a generic repository helps -- the logic only needs to be written once. I do hope in a future release, Entity can add this capability directly (and remove the restriction about having multiple instances of an object on the heap but with the same key).
Related
I have a project which uses Entity Framework extensively. And it all works fine.
However, there is one update that I am trying to make and it does not update, nor is an error thrown.
The basic process is that I take an existing entity, work with it to create a new (and different type) of entity. The new entity saves just fine, but the existing one does not.
Typically when I have encountered this, it means that the entity is not attached to the context. However, it is, and I have tried attaching it again as well as "Adding" it, but I have had no luck.
if (fileRowEntity != null)
{
this.Context.FileRowEntities.Attach(fileRowEntity);
fileRowEntity.FileRowStatusId = (int)FileRowStatus.Converted;
fileRowEntity.EdiDocument = ediDocument;
}
ediDocument.InsertedDate = DateTime.Now;
ediDocument.EdiDocumentGuid = Guid.NewGuid();
ediDocument.DocumentMetatdata = null;
this.Context.EdiDocuments.Add(ediDocument);
var count = this.Context.SaveChanges();
The ediDocument is saved, but the fileRowEntity is not saved.
I am tearing my hair out trying to figure this out. I have tried a second explicit save on the fileRowEntity but it comes back with zero changes saved:
if (fileRowEntity != null)
{
fileRowEntity.EdiDocumentId = ediDocument.EdiDocumentId;
fileRowEntity.Column100 = "X";
this.Context.FileRowEntities.Attach(fileRowEntity);
count = this.Context.SaveChanges();
}
count is always zero, and the database is not updated.
I don't know what else to try to debug this.
Attaching an entity to a context does not mark it as modified.
In your case, the presumption is that the context instance where you are calling SaveChanges() on, is not the same that retrieved the fileRowEntity object, so it doesn't know that it was modified (or what was modified).
When a DbContext retrieves an object from the store, it stores a copy of its original values (unless you used AsNoTracking() on that query), and whenever it detects changes by a call to DetectChanges(), which you can make explicitly, but the normal DbContext implementation will call it by itself at many points), it'll store the new object values. If there are differences between those, the next call to SaveChanges will update the entity in the store/database.
When you attach an entity but don't mark it as modified, it doesn't know anything has changed, so you can explicitly mark the entity as modified:
Using Context.Entry(fileRowEntity).State = EntityState.Modified; should tell EF that your entity was modified, and it'll generate the update command when you call SaveChanges() for the whole entity (it'll send all the field values in the UPDATE SQL). Note that doing this also attaches the entity if it was not attached to the context (no need to attach it and then set its state).
You can also mark only the properties that were modified (or change the entity OriginalValues), this way your query will be optimized (it'll only update the fields that have actually changed). It's a bit cumbersome to track those changes yourself, but if you need that extra optimization, it's worth a shot (personally, unless there's a critical load on the database server and every bit counts, I wouldn't do this, but your choice)
There is a second reason for the above described behavior: This code will turn off change tracking:
Context.Configuration.AutoDetectChangesEnabled = false;
After I found this had been set in the constructor and removed it, all worked as expected.
I've been trying to write some tests for my program and got a strange problem.
The db looks like one-TableOne to many TableMany (let's say so)
Initialization before every test is pretty simple. Remove everything existing and insert new ones before every test. Everything works.
[TestInitialize()]
public void MyTestInitialize() // Before every test run.
{
FixtureDbTearDown.TearDown( FixtureDbImport_95.ID );
FixtureDbImport_95.SetUp();
}
Then I have decided to use re-use fixture and clean it up. So I made all entity classes private static readonly.
Now, only first test passes, others throw an exception on duplicate key. Running tests one by one shows no errors.
Basically, this is working
private static void SetUp_Many( MyEntities entity )
{
TableMany ok1 = new TableMany { smth... };
entity.TableMany.Add( ok1 );
}
But this one not.
private static readonly TableMany ok_sr = new TableMany { smth.. };
private static void SetUp_Many( MyEntities entity )
{
entity.TableMany.Add( ok_sr );
}
Debugger shows that the second I call Add(ok_sr) entitty adds one more record to parent TableOne.
The TableOne is an exact copy of mine, no nulls and default values.
Ok, I can make a object copy before adding, most likely, the problem is with object copy because I declare things readonly. Right?
I am a little bit confused about the duplicate for TableOne.
Any ideas?
The member variable ok_sr is readonly but the object ok_sr itself isn't!
When a member is readonly you can't assign another object to it after the first assignment. But if the object itself has read/write properties or state-changing methods you can still modify the object.
This is exactly what happens here. After the first test, ok_sr has obtained a parent, a "TableOne" instance. Now when you execute ...
entity.TableMany.Add(ok_sr);
... the parent object is marked as Added as well. As for EF, it's a brand new entity, even though its primary key has a value. EF just overwrites this key value.
As a general advice, I would not use static members for unit test unless it's for genuinely read-only values, i.e. value types.
A very elegant way of cleaning up in unit tests against a database (these are, in fact, integration tests) is to start a transaction scope in the setup of each test and dispose it without committing it in each test teardown.
We have a scenario in our code when only a few properties of an entity are allowed to be changed. To guarantee that, we have code similar to this:
public void SaveCustomer(Customer customer)
{
var originalCustomer = dbContext.GetCustomerById(customer.Id);
if (customer.Name != originalCustomer.Name)
{
throw new Exception("Customer name may not be changed.");
}
originalCustomer.Address = customer.Address;
originalCustomer.City = customer.City;
dbContext.SaveChanges();
}
The problem with this code is that the call to dbContext.GetCustomerById does not always gives me a new instance of the Customer class. If the customer already has been fetched from the database, Entity Framework will keep the instance in memory and return it on every subsequent call.
This leads us to the actual problem - customer and originalCustomer may refer to the same instance. In that case, customer.Name will be equal to originalCustomer.Name and we will not be able to detect if it differs from the database.
I guess the same problem exists with most other ORMs as well, because of the identitymap design pattern.
Any ideas how this can be solved? Can I somehow force EF to always give me a new instance of the customer class?
Or should we refactor the code instead? Does anyone know of any good design patterns for this scenario?
you can try by detaching the entity from the context, this will remove all the references to the context (as well as the identitymap behaviour).
So, before passing the Customer to your method you can detach it:
yourContext.Detach(customer);
All the examples I've found refer to a class called ObjectContext, which doesn't appear to exist in CTP5. I must stress at this point, CTP5 is my first exposure to the Entity Framework.
I have a disconnected POCO that I have attached to my DbContext. SaveChanges does not pick up the change though, how I tell my context to update that entity?
_context.Users.Attach(user);
// The user has been replaced.
_context.SaveChanges();
// The change is not saved.
What am I doing wrong?
Update 12/01/2011
Might be obvious to most, but as a first time user of EF, it didn't occur to me that attaching an object that was already attached would clear the previous state. This caused me a lot of pain. But I wanted to use the Repository pattern in a very generic way, a way which didn't care if the object was already attached or had been freshly created as the result of ASP.NET MVC binding. So I needed an UpdateUser method, and I've attached it below.
public User UpdateUser(User user) {
if (_context.Entry(user).State == EntityState.Detached) {
_context.Users.Attach(user);
_context.Entry(user).State = EntityState.Modified;
}
return user;
}
The method obviously assumes that the object exists in the data store in some fashion, it's called UpdateUser after all. If the object is already attached, you will benefit from the object's previous state, which in turn will allow for an optimised update to the DB. However, if the object was not attached, the method forces the whole thing to become dirty.
Seems obvious now, wasn't before. Hope it helps someone.
Rich
When you Attach an entity, it goes to Unchanged state (it has not been changed since it attached to the context). All you need to is to explicitly change the Entity State to Modified:
_context.Users.Attach(user);
_context.Entry(user).State = System.Data.Entity.EntityState.Modified;
_context.SaveChanges();
For the sake of completeness, you can access the ObjectContext by casting the DbContext to IObjectContextAdapter:
((IObjectContextAdapter)context).ObjectContext.ObjectStateManager.ChangeObjectState(user, EntityState.Modified);
Morteza's method is much cleaner though and gets my vote.
I believe u do not need to attach the entity before u call modified. simply setting to modified will do the job.
if (_context.Entry(user).State == EntityState.Detached)
{
_context.Entry(user).State = EntityState.Modified;
}
I have an ADO.Net Data Service that I am using to do a data import. There are a number of entities that are linked to by most entities. To do that during import I create those entities first, save them and then use .SetLink(EntityImport, "NavigationProperty", CreatedEntity). Now the first issue that I ran into was that the context did not always know about CreatedEntity (this is due to each of the entities being imported independently and a creation of a context as each item is created - I'd like to retain this functionality - i.e. I'm trying to avoid "just use one context" as the answer).
So I have a .AddToCreatedEntityType(CreatedEntity) before attempting to call SetLink. This of course works for the first time, but on the second pass I get the error message "the context is already tracking the entity".
Is there a way to check if the context is already tracking the entity (context.Contains(CreatedEntity) isn't yet implemented)? I was thinking about attempting a try catch and just avoiding the error, but that seems to create a new CreatedEntity each pass. It is looking like I need to use a LINQ to Data Services to get that CreatedEntity each time, but that seems innefficient - any suggestions?
I think you should look at the EntityState property of your entity.
Only if it is of the value EntityState.Detached than you have to add it to your context.
Do not forget the following remark:
This enumeration has a FlagsAttribute
attribute that allows a bitwise
combination of its member values.
I would create a extension method:
public static class EntityObjectExtensions
{
public static Boolean IsTracked(this EntityObject self)
{
return (self.EntityState & EntityState.Detached) != EntityState.Detached;
}
}
When trying to check whether the context was tracking the entity that I wanted to update (or add) I was pretty disapointed when I found that the context.Entites.Contains(currentItem) didn't work.
I got around it using:
if (context.Entities.Where(entities => entities.Entity == currentItem).Any())
{
this.service.UpdateObject(currentItem);
}