Possible IsDirty / IsSelfDirty Issue

Possible IsDirty / IsSelfDirty Issue

Old forum URL: forums.lhotka.net/forums/t/4546.aspx


Bob Matthew posted on Monday, March 24, 2008

I’m overriding IsSelfDirty for a particular object to return “true”, but IsDirty still returns “false”.  In looking at the code in Core.BusinessBase.cs, lines 119, the IsDirty getter says the following:

Should it say the following instead?

Otherwise, I’ll have to override IsDirty as well as IsSelfDirty and implement the same code, or at least call another method.

The main problem is that during the Core.BusinessBase.cs Save method (line 118) it does an IsDirty check and ignores the IsSelfDirty.

I would assume that if an object IsSelfDirty that it would also be IsDirty as well.

RockfordLhotka replied on Tuesday, March 25, 2008

Perhaps - what do others think?

Cine replied on Tuesday, March 25, 2008

What would be a reasoning behind NOT being dirty if isselfdirty says you are?

ajj3085 replied on Wednesday, March 26, 2008

Well... if IsSelfDirty returns true, I think it would follow that IsDirty should return true as well.

JoeFallon1 replied on Wednesday, March 26, 2008

I think it makes sense for the particular case Bob is explaining. Since IsSelfDirty is Overridable he should be able to Override it and get correct answers.

But what about the reverse case??

What if (in another BO) he later wants to Override IsDirty but NOT override IsSelfDirty?

Would it work if you made the code change he is requesting for the first case? Or would this case now be broken?

Joe

ajj3085 replied on Wednesday, March 26, 2008

I don't think IsDirty would need to be overridable; if you don't want child objects, you can query IsSelfDirty. 

JoeFallon1 replied on Wednesday, March 26, 2008

I am not sure of your point. Both IsDirty and IsSelfDirty currently are Overridable. I do not see that changing.

So my original question still stands - would the reverse case be an issue if Rocky made the change requested or not?

Joe

 

ajj3085 replied on Wednesday, March 26, 2008

Well my point is that IsDirty probably shouldn't be overridable.  It probably should be changed, because otherwise you end up with the problem you state; IsDirty may return false even though IsSelfDirty returns true.. that doesn't make sense to me why you'd want that.

RockfordLhotka replied on Wednesday, March 26, 2008

Yeah, then there’s that ugly backward compatibility issue… IsDirty has always been overridable, and changing that would effectively break every parent class out there, preventing a controlled migration from <3.5 into 3.5.

 

Rocky

 

 

From: ajj3085 [mailto:cslanet@lhotka.net]
Sent: Wednesday, March 26, 2008 1:46 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Possible IsDirty / IsSelfDirty Issue

 

Well my point is that IsDirty probably shouldn't be overridable.  It probably should be changed, because otherwise you end up with the problem you state; IsDirty may return false even though IsSelfDirty returns true.. that doesn't make sense to me why you'd want that.


ajj3085 replied on Wednesday, March 26, 2008

True, but there was a time when all validation rules were instance rules too. 

The fix for someone migrating would be to remove the IsDirty override in the parent class.. which was one of the goals for 3.5.  It's just that you have to remove it instead of getting to wait until later.

I think that's better than running into the issue the OP is.. your object not being dirty when you expect it to be, and possibly spending hours trying to track down why.  I'd rather a compile error personally.


EDIT:  On second thought, this change precludes the old way of doing things completely.  So I guess it's not as cut and dry as I was thinking.

Bob Matthew replied on Wednesday, March 26, 2008

Perhaps I should chime back in on this one.

For me, it’s not really a matter of a method being marked virtual or not; being virtual makes things easier should I decide to override a method for my own purposes.  For example, if the decision is made to go with the status quo in this instance, I’ll probably override IsDirty in my base class to handle this scenario.

The heart of the matter is this:  Should IsDirty be true if IsSelfDirty is true?

Per the default IsDirty code found in the Core\BusinessBase.cs file, what it appears to be saying is “Am I marked as dirty or are any of my child objects marked dirty?”

My thought is that the first part of the question, “am I marked dirty” should probably be answered by asking the property that knows the answer, “IsSelfDirty”.

ajj3085 replied on Wednesday, March 26, 2008

Heh... well I think everyone has agreed that it probably should.Smile [:)]

RockfordLhotka replied on Wednesday, March 26, 2008

And so the change is now in svn so IsDirty and IsValid delegate to IsSelfDirty and IsSelfValid.

I didn't change what is or is not overridable - if that happens it will be in some future version.

Copyright (c) Marimer LLC