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):"
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):"
- Name: HasChanges
- Location: ChangeTracker
-
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) -
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.
-
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)