I'm using POCO generated classes - any way that I can tweek the template so that when I remove from a child collection, the item removed is also deleted from the db ?
Or maybe in the partial class I can override something, catch an event ..?
Basically I want Order.OrderDetails.Remove(orderDetail) to remove the orderDetail from db.
I do not want to access the context and do context.OrderDetails.Delete(orderDetail).
When you remove an object from a collection navigation property, Entity Framework removes the relationship between the objects (nulling the property on the child object that refers to its parent).
If you want to delete a record, you need to mark the object as State = EntityState.Deleted. You can either do that by accessing the context, or if you don't want to, a workaround would be to identify the child objects that have been orphaned in the ChangeTracker, and set their State to Deleted there.
var orphans = context.ChangeTracker.Entries().Where(e => e.State == EntityState.Modified && typeof(e.Entity) is ChildType);
foreach (DbEntityEntry orphan in orphans)
{
orphan.State = EntityState.Deleted;
}
Related
I'm debugging this method for two cases: one where there is a parent, the other where there is no parent.
If there is no parent, the new Person has an id of 0 but never actually gets saved to the db.
If there is a parent, the new Person has an id of 0 in this method, but a new record is inserted into the db with the correct value (one more than the highest in the table).
What is going on here? I know I'm doing something wrong, I'm just not sure what.
I'm using EF Codefirst.
The code for the controller method:
[HttpPost]
public ActionResult Create(CreatePersonViewModel viewModel)
{
if (ModelState.IsValid)
{
var parent = _db.Persons.FirstOrDefault(s => s.PersonId == viewModel.ParentId);
var person = new Person() { Name = viewModel.Name };
// if it has a parent, build new relationship
if (parent != null)
{
person.Parent = parent;
parent.Children.Add(person);
};
_db.Save();
return RedirectToAction("detail", "person", new { personId = person.PersonId });
}
return View(viewModel);
}
If there is no parent, the new Person has an id of 0 but never actually gets saved to the db.
That's because you never tell EF that it should persist the entity. You only create a new Person() and that's it.
You should do:
dbContext.AddToPersons(person);
before calling dbContext.SaveChanges().
In the case when there is a parent, person is saved because of its relationship with parent.
Update
Just occurred to me: If you're doing code first you might not have the AddToPersons(...) method available on the data context. If this is so, you can use dbContext.Persons.AddObject(person) instead.
The fact with you are referring to is auto increment ID for you object. It is controlled by your ORM. You may want to check this question
You may want to check this link from msdn
Remarks Refresh has the dual purpose of allowing an object to be
refreshed with data from the data source and being the mechanism by
which conflicts can be resolved. For more information, see Saving
Changes and Managing Concurrency (Entity Framework). The order in
which objects are refreshed is nondeterministic. After the Refresh
method is called, the object’s original values will always be updated
with the data source value, but the current values might or might not
be updated with the data source value. This depends on the
RefreshMode. The StoreWins mode means that the object should be
updated to match the data source values. The ClientWins value means
that only the changes in the object context will be persisted, even if
there have been other changes in the data source. To ensure that an
object has been updated by data source-side logic, you can call the
Refresh method with the StoreWins value after you call the SaveChanges
method.
I have this code in a Windows Service targeted to .Net 4.5 that uses a database-first Entity Framework layer:
var existingState = DataProcessor.GetProcessState(workerId);
existingState.ProcessStatusTypeId = (int)status;
existingState.PercentProgress = percentProgress;
existingState.ProgressLog = log;
DataProcessor.UpdateProcessState(existingState);
And this code in a data processing class in the same solution:
public ProcessState GetProcessState(int id)
{
using (var context = new TaskManagerEntities())
{
var processes = (from p in context.ProcessStates.Include("ProcessType").Include("ProcessStatusType")
where p.IsActive && p.ProcessStateId == id
select p);
return processes.FirstOrDefault();
}
}
public ProcessState UpdateProcessState(ProcessState processState)
{
using (var context = new TaskManagerEntities())
{
context.ProcessStates.Add(processState);
context.Entry(processState).State = System.Data.EntityState.Modified;
context.SaveChanges();
}
return processState;
}
ProcessState is a parent to two other classes, ProcessStatusType and ProcessType. When I run that code in the windows service, it retrieves a record, updates the entity and saves it. Despite the fact that the ProcessType child is never used in the above code, when the save on the ProcessState entity is performed, EF does an insert on the ProcessType table and creates a new record in it. It then changes the FK in the ProcessStatus entity to point it at the new child and saves it to the database.
It does not do this in the ProcessStatusType table, which is set up with an essentially identical FK parent-child relationship.
I now have a database full of identical ProcessType entries that I don't need, and I don't know why this is occurring. I feel like I'm making some obvious mistake that I can't see because this is my first EF project. Is the issue that I'm allowing the context to expire in between calls but maintaining the same entity?
Using Add will set the state of all elements to Added, which is causing the child elements to be inserted. The parent element is not inserted as you specify EntityState.Modified for this element.
Try using the following in the UpdateProcessState rather than using Add.
context.ProcessStates.Attach(processState);
context.Entry(processState).State = EntityState.Modified;
context.SaveChanges();
Attach will set the state of all elements to Unchanged and by specifying Modified for the parent element you are indicating that only this element should be updated.
On another note. You should use the strongly-typed Include(x => x.ProcessType) rather than Include("ProcessType").
In my model I have two classes Categories and Products. There is a relation many- to many between them.
I set states of all categories on modified manually and when I watched in the debugger before saveChanges() I saw that all of these categories were marked as modified. But after request mapping between categories and product weren't updated in my database. Code of update function.
public void UpdateProduct(Product product)
{
using (EFDbContext context = new EFDbContext())
{
context.Products.Attach(product);
if (product.Categories != null)
{
foreach (var item in product.Categories)
{
context.Entry(item).State = EntityState.Modified;
}
}
context.Entry(product).State = EntityState.Modified;
context.SaveChanges();
}
}
Setting entity to modified says that you have changed its properties (not navigation properties) and you want to save them. If you changed relations (navigation properties) by for example creating new relation between existing product and category or removing relation between existing product and category setting state to modified will not help you. This is actually very hard to solve (it is same in all current EF versions) because that relation has its own state which must be set and state of relation cannot be Modified = you must know if you added or removed relation. Especially removing is hard because you probably don't have information about relations you have removed from Categories navigation property when you are going to attach entity to the context. Moreover DbContext doesn't offer access to state of the relation so you must convert it to ObjectContext and use ObjectStateManager.
The easiest way to solve this issue is to load product with categories from database prior to saving and manually synchronize your detached object graph (the one you are trying to save at the moment) with loaded attached graph. Once you synchronize all changes in attached graph you will save it back to database. Attached graph will know which relations to categories were added or removed.
I have an ASP.NET MVC view for editing a model object. The edit page includes most of the properties of my object but not all of them -- specifically it does not include CreatedOn and CreatedBy fields since those are set upon creation (in my service layer) and shouldn't change in the future.
Unless I include these properties as hidden fields they will not be picked up during Binding and are unavailable when I save the modified object in my EF 4 DB Context. In actuality, upon save the original values would be overwritten by nulls (or some type-specific default).
I don't want to drop these in as hidden fields because it is a waste of bytes and I don't want those values exposed to potential manipulation.
Is there a "first class" way to handle this situation? Is it possible to specify a EF Model property is to be ignored unless explicitly set?
Use either:
public bool SaveRecording(Recording recording)
{
// Load only the DateTime property, not the full entity
DateTime oldCreatedOn = db.Recordings
.Where(r => r.Id == recording.Id)
.Select(r => r.CreatedOn)
.SingleOrDefault();
recording.CreatedOn = oldCreatedOn;
db.Entry(recording).State = EntityState.Modified;
db.SaveChanges();
return true;
}
(Edit: The query only loads the CreatedOn column from the database and is therefore cheaper and faster than loading the full entity. Because you only need the CreatedOn property using Find would be unnecessary overhead: You load all properties but need only one of them. In addition loading the full entity with Find and then detach it afterwards could be shortcut by using AsNoTracking: db.Recordings.AsNoTracking().SingleOrDefault(r => r.Id == recording.Id); This loads the entity without attaching it, so you don't need to detach the entity. Using AsNoTracking makes loading the entity faster as well.)
Edit 2
If you want to load more than one property from the database you can project into an anonymous type:
public bool SaveRecording(Recording recording)
{
// Load only the needed properties, not the full entity
var originalData = db.Recordings
.Where(r => r.Id == recording.Id)
.Select(r => new
{
CreatedOn = r.CreatedOn,
CreatedBy = r.CreatedBy
// perhaps more fields...
})
.SingleOrDefault();
recording.CreatedOn = originalData.CreatedOn;
recording.CreatedBy = originalData.CreatedBy;
// perhaps more...
db.Entry(recording).State = EntityState.Modified;
db.SaveChanges();
return true;
}
(End of Edit 2)
Or:
public bool SaveRecording(Recording recording)
{
Recording oldVersion = db.Recordings.Find(recording.Id);
recording.CreatedOn = oldVersion.CreatedOn;
// flag only properties as modified which did really change
db.Entry(oldVersion).CurrentValues.SetValues(recording);
db.SaveChanges();
return true;
}
(Edit: Using CurrentValues.SetValues flags only properties as Modified which indeed have been changed compared to the original state in the database. When you call SaveChanges EF will sent only the properties marked as modified in an UPDATE statement to the database. Whereas setting the state in Modified flags all properties as modified, no matter if they really changed or not. The UPDATE statement will be more expensive because it contains an update for all columns.)
If you don't want to send that data down to the client, I don't see any other option but to load up the original from the db in your service layer when you save and merge those original property values back in to the updated object. There's no way for EF to know that you didn't set those values to null on purpose and don't actually want to save them that way.
You could implement your own model binder that ignores the properties you don't want to pass around. Start here - http://lostechies.com/jimmybogard/2009/03/18/a-better-model-binder/
I think when you going to update use getById to get all the entity and then set your relevant properties and then you can update. It will be easy if you are using some kind of mapper (Automapper) to map your properties from view model to loaded entity from DB.
If you want to avoid making an additional (unnecessary) call to your database before every update, you can either use self-tracking entities or set StoreGeneratedPattern="Identity" for those fields in your entity model. And yes, Identity is misleading, but that sounds like the setting you'd want:
Identity A value is generated on insert and remains unchanged on update.
http://msdn.microsoft.com/en-us/library/system.data.metadata.edm.storegeneratedpattern.aspx
HI
I have a project with uses EF self tracking objects.I am trying to add a relationship to an object . (parentobject.relationshipObject.Add(New relationshipObject...)).
But it throws an error:
Cannot change ObservableCollection
during a CollectionChanged or
PropertyChanged event.
This error occurs in the #Region "Association Fixup" of the code created by the template.
Initially the mainobject does not bring any relationship. Only when the item is selected by the user the relationships are updated in the item.
i found that if i remove the MainObject from the collection and readd it with the relationships this error does not occur. if i only update the relationship object in the mainObject , this issue occurs when i add a new relationship object from the client side
any help is much appreciated
--code sequence is as follows
1. get all the parent entities.
2. when user select an entity get the relationship of the entity and update the relationship entity
parentCol.AsEnumerable.Where(Function(x) x.ID = e.Result.ID).FirstOrDefault().StopTracking()
parentCol.AsEnumerable.Where(Function(x) x.ID = e.Result.ID).FirstOrDefault().relationshipEntity = e.Result.relationshipEntity
parentCol.AsEnumerable.Where(Function(x) x.ID = e.Result.ID).FirstOrDefault().StartTracking()
to add a new item in the relationEntity
Dim newRel As New relationshipEntity
newRel.Ref_parent_Id = parentItem.ID
newRel.REF_rel_ID = relItem.Id
parentItem.relationshipEntity.Add(newRel) ---> Throws error here
the relationshipEntity denotes the relationship table between the parent entity and another entity (many to many relationship).
thanks
Are you trying to add a new child while setting the child's parent?
Since EF tries to fix up one way links on two way relationships, I assume this could cause such an issue.
E.g.
parent.Add(new Child { Parent = parent, Name = "abc" });
As opposed to letting EF do the other side of the connection
parent.Add(new Child { Name = "abc" });
or
new Child { Parent = parent, Name = "abc" });