1.0.2005.1 Final, Adapter templates.

Why does IsChanged and IsDirty remain "true" in a field when it is changed back to DBValue from a previously different value?

It doesn't track previous values you might have filled in. So if you change an initial value of 0 to 1 then 2, then 3, then 1, then 0, then 1, then 2, then 1 then 0, it will stay 'Changed'.

Otis wrote:

It doesn't track previous values you might have filled in. So if you change an initial value of 0 to 1 then 2, then 3, then 1, then 0, then 1, then 2, then 1 then 0, it will stay 'Changed'.

But doesn't it track DBValue, at least when it has been fetched? I can see the issue if it hasn't been fetched yet, but it seems like the entity should not be considered "Dirty" when the current value of a field equals its DBValue when it has been fetched, no?

Hmm. You have a point.

The thing is though that the code currently doesn't check all field values again, if it has to check if fields are changed or not, because that can hurt performance pretty badly (e.g. blobs of several megs ). So to reset the isdirty flag to false, all fields which are dirty have to be re-examined, which mitigates the whole purpose of tracking changes up front to gain performance.

Also, events have already been raised so code outside the entity has been notified something was changed. Rolling the IsDirty flag back doesn't change that.

Otis wrote:

Hmm. You have a point.

The thing is though that the code currently doesn't check all field values again, if it has to check if fields are changed or not, because that can hurt performance pretty badly (e.g. blobs of several megs ). So to reset the isdirty flag to false, all fields which are dirty have to be re-examined, which mitigates the whole purpose of tracking changes up front to gain performance.

Also, events have already been raised so code outside the entity has been notified something was changed. Rolling the IsDirty flag back doesn't change that.

Yeah, I guess I just see a difference between "Dirty" and "Changed". To me, Dirty means the entity or fields are out of sync with the database, but Changed just means something has changed about the entity, maybe even a change that put it back in sync with the database.

Could IsDirty just be a calculated property that checks the field values, or is this what you are saying would be too negative an impact on performance? (I can see not wanting to have to recheck all fields whenever a single field is changed in order to set the IsDirty flag, but isn't IsDirty used pretty infrequently, so a calculation when the Get is called wouldn't be so bad?)

As for the events, they could still be raised when a field changes value, but if the IsDirty flag were calculated, then this wouldn't be a problem. I can see that you use the IsChanged flag to indicate whether a field should result in an Update, and I suppose this would need to be changed to rely on a CurrentValue <> DBValue calculation (IsFieldDirty or something like that).

I realize that what I'm talking about is too big a breaking change for any "quick fixes" though

IMHO, the majority of people wouldn't like this change coz of performance issues. Also, the DBValue is kind of reference but doesn't guarantee that DBValue is the current value at DB. However you could change the template and add some calculated property like _IsChangedSinceLastFetch _(or something like that) and check for the CurrentValue <> DBValue condition.

IMHO, the majority of people wouldn't like this change coz of performance issues.

What is the difference in performance? Has any benchmarking been done? Isn't it "just" an extra compare when a field changes value?

I, myself, would like this feature, unless it caused an "unworkable" performance hit.

arschr wrote:

IMHO, the majority of people wouldn't like this change coz of performance issues.

What is the difference in performance? Has any benchmarking been done? Isn't it "just" an extra compare when a field changes value?

I, myself, would like this feature, unless it caused an "unworkable" performance hit.

I rethought about the re-examining of all the fields when IsChanged is reverted back to false, and this can be optimized by simply checking if there's still an IsChanged flag of a field set to true.

So for performance reasons, it doesn't have to be left out, I'm sorry for this confusion. (performance can be a problem if fieldvalues have to be compared when an entity is saved, now it's a bool check)

The thing which IS a problem is that change events have been raised. Rolling the change flags back can't roll back these events. This alone will stop this change from ending up in the code.

mikeg22 wrote:

Otis wrote:

Hmm. You have a point.

The thing is though that the code currently doesn't check all field values again, if it has to check if fields are changed or not, because that can hurt performance pretty badly (e.g. blobs of several megs ). So to reset the isdirty flag to false, all fields which are dirty have to be re-examined, which mitigates the whole purpose of tracking changes up front to gain performance. Also, events have already been raised so code outside the entity has been notified something was changed. Rolling the IsDirty flag back doesn't change that.

Yeah, I guess I just see a difference between "Dirty" and "Changed". To me, Dirty means the entity or fields are out of sync with the database, but Changed just means something has changed about the entity, maybe even a change that put it back in sync with the database.

That's why the entity doesn't have a 'changed' flag, just a 'dirty' flag which means that the entity has to be synced with the db indeed, and which fields will take part of that is determined based on the IsChanged flags of the fields. Very straightforward and fast

Could IsDirty just be a calculated property that checks the field values, or is this what you are saying would be too negative an impact on performance? (I can see not wanting to have to recheck all fields whenever a single field is changed in order to set the IsDirty flag, but isn't IsDirty used pretty infrequently, so a calculation when the Get is called wouldn't be so bad?)

When I wrote that post I overlooked one option: when an IsChanged flag of a field is set to false, the IsDirty flag is simply calculated again from all isChanged flags of all fields. That's a simple loop and an or per field.

As for the events, they could still be raised when a field changes value, but if the IsDirty flag were calculated, then this wouldn't be a problem. I can see that you use the IsChanged flag to indicate whether a field should result in an Update, and I suppose this would need to be changed to rely on a CurrentValue <> DBValue calculation (IsFieldDirty or something like that).

The IsChanged flag has to reflect if the field has a changed value or not, though the events raised are raised after the field is changed AND if the field value is accepted, the EntityContentschanged event is raised, which affects entityviews and bound controls for example. One could think of enabling a Save button because of this event. Changing a field back to false, making the entity not dirty anymore won't disable that save button.

I realize that what I'm talking about is too big a breaking change for any "quick fixes" though

It's not as easy as adding a single compare, no . As said above, I do think you have a point, though with rolling back a state of an object, you can't roll back the state of outside code/data which relied on the changed state of the object you're rolling back. So in a sense you're passing on the problem of what's in sync with what .