Issue 1043-Efficient API to ask if there are pending changes on a DbContext

Topics: EF Runtime
Apr 17, 2013 at 5:08 PM
I read the description of this issue and specially the things to be decided:

Location: we could put this on either ChangeTracker or on DbContext directly.

Naming: Pick one between HasChanges, IsDirty and changing the signature of DetectChanges to return a result.

Return value: bool or int containing number of pending changes (analogous to SaveChanges result).

I'm interested to create a new contribution for this issue, some things I'm thinking:
  • Location: ChangeTracker, is more natural because the DetectChanges is alredy here.
  • Name: HasChanges
  • Return value: return the number of changes instead of bool is a good idea
Best Regards
Apr 17, 2013 at 10:25 PM
Hi Unai,

Nice to hear from you on this so quickly :) We discussed this briefly and we came to some decisions (feel free to push back if you think these are wrong):"
  1. Name: HasChanges
  2. Location: ChangeTracker
  3. Return value: bool. The rationale for this has many parts:

    a. The name HasChanges suggests a bool value is returned
    b. The scenarios we have identified so far seem to work best (e.g. the code looks a bit nicer) with bool
    c. There are already more expensive ways of getting additional data for the different states if needed
    d. We can potentially create confusion if the numeric result from this API and SaveChanges didn't match
    e. Long term we don't necessarily want to go through the whole work that would require counting how many changes there are every time because the point is to be able to return something fast (I am not sure the implementation would do any less work anyway though)
  4. Behavior: it should respect the same contract with AutoDetectChanges as all the other APIs, e.g. the implementation should call InternalContext.DetectChanges() at the start.
  5. Method or read-only property: this is still a bit open but we are leaning towards method because it can potentially do a lot of work (e.g. if AutoDetectChanges == true)
Aug 23, 2014 at 7:04 PM
Even though HasChanges is fast, we are calling it to determine if buttons on the UI should be enabled or not in WPF CanExecute relay command. What is wrong with a HasChangesChanging event? (or whatever you might want to call it).

Aug 29, 2014 at 6:47 PM
@InTheEvent The DbSet.Local property returns an observable collection that will let you know when entities are added and removed. You can also implement INotifyPropertyChanged on your entity types to get notifications about when some property in the entity is changed. In general EF does not know when some property of an entity has changed unless you ask EF to check. So having an event would not be especially helpful here since it would only ever trigger as part of your code calling into EF with something like HasChanges.