I am currently developping an application which object model and persistence layer is built using the Entity Framework model designer.
One of the requirements I have is to provide a status to my entities that could let me know whenever they are in a "dirty" state (modified), when the status change occurs and, most important, working in a disconnected mode. So I started modifying the T4 template to add a IsDirty boolean property upon generation of those entities, added an event that is fired whenever IsDirty changes and added this.IsDirty = true in the xxxChanged methods of all scalar properties.
Everything works great when the entity is not attached to its context but when attached, whenever a property is changed, thus changing the IsDirty value to false, I receive this exception:
The property 'IsDirty' does not have a valid entity mapping on the
entity object. For more information, see the Entity Framework
documentation.
So what am I doing wrong here? I don't want this property to be mapped in my database as it is just an object status that only matters when the object is "alive". Is there an attribute I should use to decorate the IsDirty property? Or should I derive EntityObject and implement the status mechanism? Or maybe you have any better advice on how to implement this?
Thanks.
Edit: I am using Entity Framework 4.0 with EDM designer.
Here is the piece of code generated into every base entity:
private bool isDirty;
public event EventHandler DirtyStatusChanged;
public bool IsDirty
{
get
{
return this.isDirty;
}
internal set
{
if (this.isDirty != value)
{
ReportPropertyChanging("IsDirty");
this.isDirty = value;
ReportPropertyChanged("IsDirty");
ReportDirtyStatusChanged();
}
}
}
protected void ReportDirtyStatusChanged()
{
var handler = this.DirtyStatusChanged;
if(handler != null)
{
handler(this, EventArgs.Empty);
}
}
I finally found the error myself. The problem lied inside my property setter. Instead of calling ReportPropertyChanged/ing I should have called OnPropertyChanged/ing.
ReportPropertyChanged/ing implies for the context to search for changes between the original and the current entity value but as this property is just a status object that has no mapping to a store, the concept of original value makes no sense, thus making the context failing to find a correct mapping for this property.
Using OnPropertyChanged/ing just fixed it.
Related
I stumbled upon unexpected behaviour when using Entity Framework with PostgreSql.
When I query context with navigation property inside where clause, its always null and fails. But If I add there Include method pointing to navigational propery it's working
this will work
context.Garages.Include("PostalCode").Where(f=>f.PostalCode.RegionId == regionId)
this will not (PostalCode is null and fails on NullReference)
context.Garages.Where(f=>f.PostalCode.RegionId == regionId)
I don't think I had to add this to query when using MSSQL. Can anybdoy explain this to me.
If you want that your navigation properties be lazy loaded, then you need to declare them as virtual:
public Garage
{
//...
public virtual PostalCode PostalCode {get;set;}
}
In this link you will find the conditions that must follow your entities if you want to enable lazy loading for your entities and to have the Entity Framework track changes in your classes as the changes occur.
If that navigation property is already virtual, the other option that I think could cause that behavior is if you turn off Lazy Loading on your context:
public class YourContext : DbContext
{
public YourContext()
{
this.Configuration.LazyLoadingEnabled = false;
}
}
If you call the Include method, you are going to load the related entity as part of the query. This load behavior is called Eager Loading. On the other hand, if you use Lazy Loading, the related entity is going to be loaded the first time that is accessed, that is the behavior that you looking for.
I'm using EF5 code-first with proxy-based changed tracking in my ASP.NET MVC application.
One of my domain classes contains a numeric property which is updated very frequently. For this reason, this property is not persisted to the database using the framework:
public virtual int CurrentSessions
{
get
{
return _currentSessions;
}
set
{
Interlocked.Exchange(ref _currentSessions, value);
}
}
The issue I'm facing is that the value of the property is not updated across sessions. My API controller either increases the above value or decreases it, according to internal logic, as follows:
myObj.CurrentSessions++;
or
myObj.CurrentSessions--;
where myObj is a proxied object retrieved from a context via LINQ in each session:
var myObj = objectContext.Instances<myPocoEntity>().FirstOrDefault(cb => cb.SomeProp == someValue);
When I inspect the value of myObj.CurrentSessions after it has been increased/decreased, it is indeed updated, but on the next server request, when myObj is retreived again, CurrentSessions has always its initial value, zero.
How can I make sure the property value is updated in the POCO entity without scanning the entire context for changes?
If I understand your question correctly, you have separate DbContext objects and when one updates an object the other isn't seeing the changes until the next request for the object in the database?
If so, you may be able to reload the object in question via the DbEntityEntry class.
You could then either utilize the "Reload()" method or "GetDatabaseValues()" method to obtain the values that current exist in the database.
Example(s)
// Reload Usage
context.Entry(entity).Reload();
// GetDatabaseValues Usage
DbPropertyValues propertyValues = context.Entry(entity).GetDatabaseValues();
foreach (DbPropertyValue val in propertyValues)
{
...
}
Im writing an web application with MVC using Entity Framework for my backend logic. My problem is that I have an entity that has certain fields that should never be changed on an update. I am not really sure what the best way to solve this problem would be. There is going to be a lot of data processed in my application, so I cant afford to just hack up a solution.
Is it possible to just define the fields as readonly in the POCO entities ? Or should I write and entity framework extension class that validates all updates. Could it be done in the mapping files between EF and the actual database?
I am relatively new with EF, so I hope some of you might be able to give me some pointers!
Thanks!
If you are using .NET 4.5 and EF 5 (i.e. MVC 4), you can simply set IsModified = false on the individual properties in question. This has the benefit of sticking close to the default out-of-the-box MVC conventions.
For example, if you have a CreatedBy field that shouldn't be touched when the record is updated, use the following in your controller:
[HttpPost]
public ActionResult Edit(Response response)
{
if (ModelState.IsValid)
{
db.Entry(response).State = EntityState.Modified;
db.Entry(response).Property(p => p.CreatedBy).IsModified = false;
db.SaveChanges();
return RedirectToAction("Index");
}
return View(response);
}
Note that the IsModified line is the only change from the default controller action.
You MUST put this line AFTER setting .State = EntityState.Modified (which applies to the record as a whole and adds the record into the db context).
The effect is that EF will not include this column in the SQL UPDATE statement.
I am still (very) shocked that there are no [InsertOnly] or [UpdateOnly] attributes similar to [ReadOnly]. This seems like a major oversight by the MVC team. Am I missing something?
I'm not fully satisfied with this solution because it's a hack: You're telling EF that no change was made when what you really mean to say is "HANDS OFF". It also means that you have to use this code anyplace where the field could be updated. It would be better to have an attribute on the class property.
(Apologies for posting to an older thread, but I've not see this solution anywhere else. ViewModels are robust but a lot of work, and EF was supposed to make things easier, not harder...)
Well I would advice against ever using the EF classes in the View. You're best bet is to construct ViewModel classes and use Automapper to map them from the EF classes.
When you are updating records in the database though, you can control which fields in the ViewModel are used to update the existing fields in the EF class.
The normal process would be:
Use the Id to get the latest version of the existing object out of the database.
If you are using optimistic concurrency control then check that the object has not been updated since the ViewModel was created (so check timestamp for example).
Update this object with the required fields from your ViewModel object.
Persist the updated object back to the database.
Update to include Automapper examples:
Let's say your POCO is
public class MyObject
{
public int Id {get;set;}
public string Field1 {get;set;}
public string Field2 {get;set;}
}
and Field1 is the field you don't want updating.
You should declare a view model with the same properties:
public class MyObjectModel
{
public int Id {get;set;}
public string Field1 {get;set;}
public string Field2 {get;set;}
}
and Automap between them in the constructor of your Controller.
Mapper.CreateMap<MyObject, MyObjectModel>();
you can if you wish (although I prefer to do this manually, automap the other way too:
Mapper.CreateMap<MyObjectModel, MyObject>().ForMember(dest=>dest.Field1, opt=>opt.Ignore());
When you are sending date to your website you would use:
var myObjectModelInstance = Mapper.Map<MyObject, MyObjectModel>(myObjectInstance);
to create the viewModel.
When saving the data, you'd probably want something like:
public JsonResult SaveMyObject(MyObjectModel myModel)
{
var poco = Mapper.Map<MyObjectModel, MyObject>(myModel);
if(myModel.Id == 0 )
{
//New object
poco.Field1 = myModel.Field1 //set Field1 for new creates only
}
}
although I'd probably remove the exclusion of Field1 above and do something like:
public JsonResult SaveMyObject(MyObjectModel myModel)
{
var poco;
if(myModel.Id == 0)
{
poco = Mapper.Map<MyObjectModel, MyObject>(myModel);
}
else
{
poco = myDataLayer.GetMyObjectById(myModel.Id);
poco.Field2 = myModel.Field2;
}
myDataLayer.SaveMyObject(poco);
}
note I believe that best-practise would have you never Automap FROM the ViewModel, but to always do this manually, including for new items.
I just asked a very similar question, and I believe the answer to that one may help out a lot of folks who stumble across this one as well. The OP mentions that these are fields that should never change, and using PropertySaveBehavior.Ignore ensures this. With the existing answers to this question, you need to make custom save methods or introduce mapping where it might not make sense. By setting the AfterSave property behavior instead, you can prevent this from being possible in EF altogether.
In my project, I am generically accessing a property that is on an abstract class so I have to set it like this:
MyProperty.SetAfterSaveBehavior(PropertySaveBehavior.Ignore);
If you're accessing it directly on a known class, you'd use this:
...
.Property(e => e.YourProperty)
.Metadata.SetAfterSaveBehavior(PropertySaveBehavior.Ignore);
I've just implemented a repository based on EFv4 POCO entity templates.
When I do this
public Client Load(Guid firmId,
int prettyId)
{
var client = (from c in _ctx.Clients where c.firm_id == firmId && c.PrettyId == prettyId select c).FirstOrDefault();
return client;
}
the client returned is of type
{System.Data.Entity.DynamicProxies.Client_8E92CA62619EB03F03DF1A1FC60C5B21F87ECC5D85B65759DB3A3949B8A606D3}
What is happening here? I thought I would get rid of any reference to types from System.Data.Entity namespace. The returned instance should be of type Client, which is a simple POCO class.
I can confirm that the solution is to set
context.ProxyCreationEnabled = false;
which disables creation of dynamic proxy typed objects and leaves us with simple POCOs, which is what we were after with EF POCO templates in the first place.
But you lose lazy loading of navigation properties and change tracking on entities. For the first, you either have to use context.LoadProperty() or the Include() method on your ObjectQuery object. For the second, I do not know the solution yet (actually it doesn't really make sense to have change tracking on POCOs).
Also here is a similar question I would like to point out
What are the downsides to turning off ProxyCreationEnabled for CTP5 of EF code first
I agree that Mare's answer is correct. However, I would add a note of caution.
If you run a query without this ProxyCreationEnabled setting set to true, then EF will return DynamicProxies. If you subsequently run a query with the setting set to false, then EF will return the cached DynamicProxies objects, regardless of the ProxyCreationEnabled setting.
This can be configured globally for the EF context in the *Model.Context.tt file in *Model.edmx under
if (!loader.IsLazyLoadingEnabled(container))
...
this.Configuration.LazyLoadingEnabled = false;
this.Configuration.ProxyCreationEnabled = false;
These will be added to the *Model.context.cs generated file, and will persist between updates from the Database.
I prefer this setting as I do not want a child object that matches the parent loaded from the database.
ALT: It can be configured for Json serizialization:
JSON.NET Error Self referencing loop detected for type
When setting a property on an entity object, it is saving the value to the database even if the value is exactly the same as it was before. Is there anyway to prevent this?
Example:
If I load a Movie object and the Title is "A", if I set the Title to "A" again and SaveChanges() I was hoping that I wouldn't see the UPDATE statement in SqlProfiler but I am. Is there anyway to stop this?
Yes, you can change this. Doing so isn't trivial, however, in the current version of the Entity Framework. It will become easier in the future.
The reason you're seeing this behavior is because of the default code generation for the entity model. Here is a representative example:
public global::System.Guid Id
{
get
{
return this._Id;
}
set
{
// always!
this.OnIdChanging(value);
this.ReportPropertyChanging("Id");
this._Id = global::System.Data.Objects.DataClasses
.StructuralObject.SetValidValue(value);
this.ReportPropertyChanged("Id");
this.OnIdChanged();
}
}
private global::System.Guid _Id;
partial void OnIdChanging(global::System.Guid value);
partial void OnIdChanged();
This default code generation is reasonable, because the Entity Framework doesn't know the semantics of how you intend to use the values. The types in the property may or may not be comparable, and even if they are, the framework can't know how you intend to use reference equality versus value equality in all cases. For certain value types like decimal, it's pretty clear, but in a general sense it's not obvious.
You, on the other hand, know your code, and can customize this some. The trouble is that this is generated code, so you can't just go in and edit it. You need to either take over the code generation, or make it unnecessary. So let's look at the three options.
Take over the code generation
The essential approach here is to create a T4 template which does the code behind, and that the default code generation from the Entity Framework. Here is one example. One advantage of this approach is that the Entity Framework will be moving to T4 generation in the next version, so your template will probably work well in future versions.
Eliminate code generation
The second approach would be to eliminate cogeneration altogether, and do your change tracking support manually, via IPOCO. Instead of changing how the code is generated, with this approach you don't do any code generation at all, and instead provide change tracking support to the Entity Framework by implementing several interfaces. See the linked post for more detail.
Wait
Another option is to live with the Entity Framework the way it is for the time being, and wait until the next release to get the behavior you desire. The next version of the Entity Framework will use T4 by default, so customizing the code generation will be very easy.
According to MSDN:
The state of an object is changed from
Unchanged to Modified whenever a
property setter is called. This occurs
even when the value being set is the
same as the current value. After the
AcceptAllChanges method is called, the
state is returned to Unchanged. By
default, AcceptAllChanges is called
during the SaveChanges operation.
Looks like you'll want to check the value of properties on your Entity objects before you update to prevent the UPDATE statement.
At a generic level, if your entities are implementing INotifyPropertyChanged, you don't want the PropertyChanged event firing if the value is the same. So each property looks like this :-
public decimal Value
{
get
{
return _value;
}
set
{
if (_value != value)
{
_value = value;
if (_propertyChanged != null) _propertyChanged(this, new PropertyChangedEventArgs("Value"));
}
}
}
Hope that's relevant to Entity Framework.
One thing you can do is just wrap the property yourself using a partial class file, and then use your property instead of the first one:
public sealed partial class MyEFType {
public string MyWrappedProperty {
get {
return MyProperty;
}
set {
if (value == MyProperty)
return;
MyProperty = value;
}
}
}
It wouldn't be very practical to do this to every property, but if you have a need to detect that a particular property has actually changed and not just been written to, something like this could work.