I am using EF 6. I have a two tier application using WCF Soap and DTOs to transfer data. I send an object graph across the wire for the user to update, and then send it back to persist the changes. In between, I use AutoMapper to convert to and from DTOs and entities.
On the persistence side, I receive my DTO and unpack it (it contains lists of entities). I unpack it into the appropriate entities and check whether we are adding or editing by checking if the id is 0. So far I have just blindly updated every entity whose id > 0.
However, I have learned this is not the best way because it throws unnecessary concurrency exceptions. If I just call update on the entity, the rowversion gets updated, even if no fields actually changed values in the database. This is causing unnecessary concurrency exceptions. I need to avoid these. So I need to somehow check to see if an entity really needs to be updated or not. The only way I know how to check whether an entity needs to be updated, is to query the database and do a property by property check.
My question: Am I on the right track? Do I in fact really need to check an entity property by property to find out if it needs to be updated? Is there an easier or more automatic way?
I feel frustrated by the need to query the database for each entity before saving changes. Maybe I am missing something?
Here is a sample of my code:
var ws = saveRequest.Workspace;
var td = saveRequest.ToDelete;
using (var db = new EngineeringContext())
{
var ass = Attach<JobAssembly>(db, db.JobAssemblies, ws.Assemblies.ToDomain());
var opr = Attach<JobOperation>(db, db.JobOperations, ws.Operations.ToDomain());
var mtl = Attach<JobMaterial>(db, db.JobMaterials, ws.Materials.ToDomain());
Delete<JobAssembly>(db, td.Assemblies.ToDomain());
Delete<JobOperation>(db, td.Operations.ToDomain());
Delete<JobMaterial>(db, td.Materials.ToDomain());
try
{
db.SaveChanges();
}
catch (DbUpdateConcurrencyException ex)
{
throw new Exception("Sync Error: The data failed to save due to changes by another user.", ex);
}
ws.Assemblies = ass.ToDto();
ws.Operations = opr.ToDto();
ws.Materials = mtl.ToDto();
}
Where Attach and Delete look something like this:
db.Entry<T>(entity).State = EntityState.Modified; // .Deleted for deletes.
And ToDomain and ToDto are extensions that map domains (entities) to dtos and viceversa.
Related
How would you Upsert without select? the upsert would be a collection of entities received by a method which contains DTOs that may not be available in the database so you can NOT use attach range for example.
One way theoretically is to load the ExistingData partially with a select like dbContext.People.Where(x => x exists in requested collection).Select(x => new Person { Id = x.Id, State = x.State }).ToList() which just loads a part of the entity and not the heavy parts. But here if you update one of these returned entityItems from this collection it will not update because of the new Person its not tracking it and you also cannot say dbContext.Entry<Person>(person).State = Modified because it will throw an error and will tell you that ef core is already "Tracking" it.
So what to do.
One way would be to detach all of them from the ChangeTracker and then do the state change and it will do the update but not just on one field even if you say dbContext.Entry<Person>(person).Property(x => x.State).Modified = true. It will overwrite every fields that you haven't read from the database to their default value and it will make a mess in the database.
The other way would be to read the ChangeTracker entries and update them but it will also overwrite and it will consider like everything is chanaged.
So techinically I don't know how ef core can create the following SQL,
update People set state = 'Approved' where state != 'Approved'
without updating anything else. or loading the person first completely.
The reason for not loading your data is that you may want to update like 14000 records and those records are really heavy to load because they contain byte[] and have images stored on them for example.
BTW the lack of friendly documentation on EFCore is a disaster compare to Laravel. Recently it has cost us the loss of a huge amount of data.
btw, the examples like the code below will NOT work for us because they are updating one field which they know that it exists in database. But we are trying to upsert a collection which some of those DTOs may not be available in the database.
try
{
using (var db = new dbContext())
{
// Create new stub with correct id and attach to context.
var entity = new myEntity { PageID = pageid };
db.Pages.Attach(entity);
// Now the entity is being tracked by EF, update required properties.
entity.Title = "new title";
entity.Url = "new-url";
// EF knows only to update the propeties specified above.
db.SaveChanges();
}
}
catch (DataException)
{
// process exception
}
Edit: The used ef core version is #3.1.9
Fantastic, I found the solution (You need to also take care about your unit tests).
Entityframework is actually working fine it can be just a lack of experience which I'm documenting here in case anyone else got into the same issue.
Consider that we have an entity for Person which has a profile picture saved as Blob on it which causes that if you do something like the following for let's say 20k people the query goes slow even when you've tried to have enough correct index on your table.
You want to do this query to update these entities based on a request.
var entityIdsToUpdate = request.PeopleDtos.Select(p => p.Id);
var people = dbContext.People.Where(x => entityIdsToUpdate.Contains(x.Id)).ToList();
This is fine and it works perfectly, you will get the People collection and then you can update them based on the given data.
In these kind of updates you normally will not need to update images even if you do, then you need to increase the `TimeOut1 property on your client but for our case we did not need to update the images.
So the above code will change to this.
var entityIdsToUpdate = request.PeopleDtos.Select(p => p.Id);
var people = dbContext.People
.Select(p => new Person {
Id = p.Id,
Firstname = p.Firstname,
Lastname = p.Lastname,
//But no images to load
})
.Where(p => entityIdsToUpdate.Contains(p.Id)).ToList();
But then with this approach, EntityFramework will lose the track of your entities.
So you need to attach it like this and I will tell you how NOT to attach it.
This is the correct way for a collection
dbContext.People.AttachRange(people); //These are the people you've already queried
Now DO NOT do this, you may want to do this because you get an error from the first one from EntityFramework which says the entity is already being tracked, trust it because it already is. I will explain after the code.
//Do not do this
foreach(var entry in dbContext.ChangeTracker.Entries())
{
entry.State = EntityState.Detached;
}
//and then on updating a record you may write the following to attach it back
dbContext.Entry(Person).State = EntityState.Modified;
The above code will cause EntityFramework not to follow the changes on the entities anymore and by the last line you will tell it literally everything edited or not edited is changed and will cause you to LOSE your unedited properties like the "image".
Note: Now what can u do by mistake that even messes up the correct approach.
Well since you are not loading your whole entity, you may assume that it is still fine to assign values to the unloaded ones even if the value is not different than the one in the database. This causes entity framework to assume that something is changed and if you are setting a ModifiedOn on your records it will change it for no good reason.
And now about testing:
While you test, you may get something out from database and create a dto from that and pass the dto with the same dbContext to your SystemUnderTest the attach method will throw an error here which says this entity is already bein tracked because of that call in your test method. The best way would be create a new dbContext for each process and dispose them after you are done with them.
BTW in testing it may happen that with the same dbContext you update an entity and after the test you want to fetch if from the database. Please take note that this one which is returning to you is the "Cached" one by EntityFramework and if you have fetched it in the first place not completely like just with Select(x => ) then you will get some fields as null or default value.
In this case you should do DbContext.Entry(YOUR_ENTRY).Reload().
It is a really complete answer it may not directly be related to the question but all of the things mentioned above if you don't notice them may cause a disaster.
My .net web service reads an entity from the DB and sends it to a client application.
The client application modifies some fields in the entity and then submits the entity back to the server to be updated in the DB.
The surefire but laborious way to do this goes something like:
public void Update(MyEntity updatedEntity)
{
using (var context = new MyDataContext())
{
var existingEntity = context .MyEntities.Single(e => e.Id == updatedEntity.Id);
existingEntity.FirstName = updatedEntity.Name;
existingEntity.MiddleName = updatedEntity.MiddleName;
existingEntity.LastName = updatedEntity.LastName;
// Rinse, repeat for all members of MyEntity...
context.SubmitChanges();
}
}
I don't want to go down this path because it forces me to specify each and every member property in MyEntity. This is will likely break in case MyEntity's structure is changed.
How can I take the incoming updatedEntity and introduce it to LINQ to SQL whole for update?
I've tried achieving this with the DataContext's Attach() method and entered a world of pain.
Is Attach() the right way to do it? Can someone point to a working example of how to this?
Attach is indeed one way to do it.
That said...
The surefire but laborious way to do this goes something like
The right way if you ask me.
This is will likely break in case MyEntity's structure is changed
I personally would expect to modify my Update business method in case the database schema has changed:
if it's an internal change that doesn't change the business, then there is just no reason to modify the code that calls your business method. Let your business method be in charge of the internal stuff
if it's some change that require you to modify your consumers, then so be it, it was required to update the calling code anyway (at least to populate for instance the new properties you added to the entity)
Basically, my opinon on this subject is that you shouldn't try to pass entities to your business layer. I explained why I think that in a previous answer.
I have an windows service which processes input from xml files. I need to insert new records and update the existing records every time I get a new file. I now need to implement insert\update history every time after an operation has occurred. I am required to maintain this in a separate table by displaying old value and new value. Is there any existing methodologies or techniques available for implementing this in easier way i.e something like comparing two objects and identifying modified fields. Please provide any suggestions. I am using Entityframework 5.0 and sql 2012.
There are multiple ways to do this.
Using interceptors of your persistence API framework. For eg JPA or Hibernate framework provides facade around your entity operations which runs after DML operations in database.
Event Listeners: You should be able to create event listeners inside your persistence framework which will be triggered and insert history data in your history tables after each DML operation.
Database triggers: This is indeed one of the most simplest way of maintaining history information for a given row/table.
Hope these pointers help
Anant
Specifically for EF, you can override DbContext.SaveChanges() and iterate over DbContext.ChangeTracker.Entries(). Each entry contains the current and original values for the properties of the entity.
My Entity class was derived from ObjectContext, which did not provide ChangeTracker for obtaining the modified values. However, for ObjectContext, we can obtain the modified values using DBContext.ObjectStateManager.GetObjectStateEntries(EntityState.Modified)
You can use EntityState.Deleted, EntityState.Added if required.
The below is the sample Implementation
Entities DBContext = new Entities();
var d = DBContext.StudentTableName.Where(x => x.stname == "Stock").FirstOrDefault();
if(d!= null)
{
d.Id = "345";
DBContext.StudentTableName.ApplyCurrentValues(d);
//Need to Include Audit Logging before save, or can override save function.
var entrList = DBContext.ObjectStateManager.GetObjectStateEntries(EntityState.Modified);
foreach (var stateEntry in entrList)
{
var currentValues = stateEntry.CurrentValues;
var originalValues = stateEntry.OriginalValues;
var modifiedProperties = stateEntry.GetModifiedProperties();
foreach (string modifiedProperty in modifiedProperties)
{
var currentValue = currentValues.GetValue(currentValues.GetOrdinal(modifiedProperty));
var originalValue = originalValues.GetValue(originalValues.GetOrdinal(modifiedProperty));
if (!originalValue.Equals(currentValue))
{
//Perform the logging operation
}
}
}
// Audit Logging Performed
DBContext.SaveChanges();
}
We've been using EF STEs for a while, but our application has grown quite a bit and we decided to sue the new 4.1 DbContext so we can "evolve" a separate business layer on top of our data layer without having to use different types for it.
In the elementary evaluation for the DbContext way of doing things, I am facing a little problem.
I am used to query and preload required related data like:
return context.Orders.Include("Detail").SingleOrDefault(ord => ord.ID == ID);
And then send the returned object to the UI for modification, and when returned from the UI save the changes to the database.
From what I read so far, doing the "change saving" in DbContext is easily done using code like this:
context.Entry(order).State = EntityState.Modified;
The problem with this code is that it actually marks all properties in the object as modified, a thing that's not allowed for some properties in my model (a business rule).
I resorted to the following solution (which seems to require a lot of code for a relatively small requirement! BTW, changing a modified property state to Unchanged is not supported):
context.Orders.Attach(order);
DbEntityEntry<Order> ordEntity = context.Entry(order);
string[] arr =
{
ordEntity.Property(ord => ord.ID).Name,
ordEntity.Property(ord => ord.ClientID).Name,
};
foreach (string prop in ordEntity.OriginalValues.PropertyNames)
{
if (!arr.Contains(prop))
{
ordEntity.Property(prop).IsModified = true;
}
}
context.SaveChanges();
The problem I am facing with this code is that the "Attach" statement is throwing an exception saying that there is some sort of conflict in the navigation properties in the attached object, even if no changes were made to anything at all! (saving the object exactly as it was retrieved from the database).
The error message is something like:
"Conflicting changes to the role 'Detail' of the relationship 'OrdersDatamodel.FK_Order_Detail' have been detected."
The questions are:
Is there a more "elegant" way for preventing the modification of certain object properties?
Does anybody know what's going on with the exception raised when attaching the object to the context?
Thanks.
From what I read so far, doing the "change saving" in DbContext is easily done using code like this:
context.Entry(order).State = EntityState.Modified;
You rarely need to explicitly set the state. When you modify properties, assuming they are virtual, the state will automatically change to Modified without you having to set it. Otherwise, DetectChanges will pick this up during your call to SaveChanges.
I have an update function in my repository which updates TerminalCertification entity. But this entity has a many to many relation to another class ( GomrokJustification ).
my update function update entity correctly but does not anything on related entity.
my update function is below:
public void UpdateTerminalCertification(TerminalCertification terminalCertification)
{
var lastCertification =
db.terminalCertifications.Include("TimeInfo").Include("GomrokJustifications").Where(item=>item.TerminalCertificationID==terminalCertification.TerminalCertificationID).ToList();
if (lastCertification.Count==0)
throw new TerminalCertificationNotFoundException(terminalCertification);
terminalCertification.TimeInfo = lastCertification[0].TimeInfo;
((IObjectContextAdapter)db).ObjectContext.Detach(lastCertification[0]);
((IObjectContextAdapter)db).ObjectContext.AttachTo("terminalCertifications", terminalCertification);
foreach (var gomrokJustification in terminalCertification.GomrokJustifications)
{
((IObjectContextAdapter)db).ObjectContext.AttachTo("gomrokJustifications", gomrokJustification);
((IObjectContextAdapter)db).ObjectContext.ObjectStateManager.ChangeObjectState(gomrokJustification, EntityState.Modified);
}
((IObjectContextAdapter) db).ObjectContext.ObjectStateManager.ChangeObjectState(terminalCertification,EntityState.Modified);
}
and my TerminalCetrification has a list of GomrokJustifications which was filled before by some entities. I want to those last entity being replaced by new ones. but this was not happen.
does anyone have any idea?
Instead of doing this:
var lastCertification = db.terminalCertifications
.Include("TimeInfo")
.Include("GomrokJustifications")
.Where(item=>item.TerminalCertificationID==terminalCertification.TerminalCertificationID)
.ToList();
if (lastCertification.Count==0)
throw new TerminalCertificationNotFoundException(terminalCertification);
you could just do this:
var lastCertification = db.terminalCertifications
.Include("TimeInfo")
.Include("GomrokJustifications")
.Where(item=>item.TerminalCertificationID==terminalCertification.TerminalCertificationID)
.FirstOrDefault();
if (lastCertification == null)
throw new TerminalCertificationNotFoundException(terminalCertification);
First throws an exception if there are no elements in the collection, so if you don't care about the terminalcertificationnotfoundexception you could even remove that custom exception. Your logic even seems to assume that there will be only one element in the returned list so you could even use Single(). That expresses more what you want to achieve compared to calling tolist and then retrieving the first item.
After looking carefully at your code I actually don't get the point you are trying to achieve here. You have an existing terminalcertification entity to start with, you then retrieve it again in that first query, why? You then take the timeinfo from conceptually the same entity (cause you did a get by id) to the one you get as input parameter. Why not continue working on the one that was retrieved from the database? You then detach the entity you received from the database, why? And continue working with the input terminalcertification. I think you need to look a bit more carefully on the entity framework documentation about entity state etc. Take a look at ApplyCurrentValues and detaching and attaching objects here: http://msdn.microsoft.com/en-us/library/bb896271.aspx
We'll need some more info to help you along.