Proxy-based change tracking, property not updated in POCO object - entity-framework

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)
{
...
}

Related

Implementing a custom non-mapped property on entities

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.

Saving single objects with Entity Framework code first

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).

Force Entity Framework to return a new instance

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);

Entity Framework v4 POCO templates: repository returns object of incorrect type

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

In ADO.Net Data Services how do I check if an entity is already in the context?

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);
}