Should Update be called on child which isn't dirty?

[ajohnstone-ks]

I'm investigating an issue I'm having with one of our business objects. It stems from the fact that the [UpdateChild] method is being called on the child collection even though the collection and all of its children are not dirty.

I had thought that FieldManager.UpdateChildren would not call the Update method for anything unless the instance though it was dirty, but that's what's happening here and causing our bug.

We're using Csla 5.4.2 on .net framework.

[rockfordlhotka]

I thought that too. Well, to be precise, I think it always calls the collection's method, and the default implementation in BusinessListBase only cascades the call to a child that's been deleted or that is dirty.

csla/Source/Csla/BusinessListBase.cs

Line 922 in e529159

if (child.IsDirty) await dp.UpdateChildAsync(child, parameters).ConfigureAwait(false);

[ajohnstone-ks]

In our case we have an update method defined in the collection class:

[UpdateChild]
private void Update(IDbConnection conn, Parent parent);

The fact that this gets calls seems inconsistent to me; if the list is not dirty (no items its DeletedList, and none of the children report being dirty), it seems like the update on the collection itself shouldn't be called. In my case, I had to do a precondition and if !IsDirty then immediately return, but that's not something you'd have to do on BB objects.

Does it make sense to put a ticket in to change the behavior so its consistent? Or is there some reason I'm not seeing that it should be called for collections BOs but not non-collection BOs?

[rockfordlhotka]

I believe this is a performance thing, because calling IsDirty on a list requires that the list walk through the entire object graph below the list (children, grandchildren, etc.) to resolve the IsDirty value. If it is dirty, then the code will walk through the entire object graph again to save each child.