EditableRoot.Save(true); does not set IsDirty to true.

bniemyjski posted on Tuesday, January 26, 2010

Hello,

I am creating a set of unit tests for PetShop and I have the following test that fails:

category = category.Save(true);

Assert.IsFalse(category.IsNew);
Assert.IsTrue(category.IsDirty); // Fails: Save docs say this should be the case..
Assert.IsFalse(category.IsDeleted);

According to the documentation .Save(true) should set IsNew to false and IsDirty to true.

Thanks
-Blake Niemyjski

ajj3085 replied on Tuesday, January 26, 2010

I think you misunderstand the purpose; it sets IsNew to false and IsDirty to true, THEN does the normal save. This allows you to bypass fetching the object from the database to do the update, and is usually used in Asp.Net.

rxelizondo replied on Tuesday, January 26, 2010

Documentation says:

This is done by first calling MarkOld() to set IsNew to false, and then calling MarkDirty() to set IsDirty to true.

Code says:

public T Save(bool forceUpdate)
{
if (forceUpdate && IsNew)
{
MarkOld();
MarkDirty(true);
}
return this.Save();
}

The documentation is correct, what you are missing is that *after* what the doc says, the procedure also runs the regular Save(). just like Andy pointed out.

bniemyjski replied on Tuesday, January 26, 2010

I think the documentation on that method needs to be updated. It is not clear that is the behavior from reading the xml documentation. I agree that save can alter the IsDirty / IsNew. The documentation should read as follows: The Type will be marked as IsNew to false and IsDirty to true before Save Is called.

Marjon1 replied on Tuesday, January 26, 2010

The fact that you are calling the save method should be indication enough that the the object will be saved. The parameter naming also makes it pretty obvious that you are attempting to force the save to occur.

Documentation can only get you so far.

lukky replied on Tuesday, January 26, 2010

Marjon:
Documentation can only get you so far.

Uuugghhh.... sometimes it's the ONLY thing you have !

Having had to work with the API of a german software, I can tell you that parameter naming can take you for a joy ride. And of course, no source available....

RockfordLhotka replied on Tuesday, January 26, 2010

The behavior has changed back and forth a couple times over the years.

And your description isn't really correct either. It isn't that the metastate changes before Save() - it changes before each individual call to DataPortal_XYZ and/or Child_XYZ.

For the longest time it occurred after the DP_XYZ calls, specifically to avoid this type of coding mistake on the part of the object developer. But that meant that your code inside the DP_XYZ methods couldn't really use the metastate, which is a very real problem.

So a while back (I don't remember the version anymore) I changed the data portal to set the metastate before calling the DP_XYZ methods. This means those methods can use the metastate, but it also means that the developer is now responsible for getting their DP_XYZ code correct.

That's probably for the best anyway - it really isn't ideal for a framework to cover up bugs like it used to do.