I have a businessListBase where I don't want the updates to succeed or fail as a transaction. If record 5 of 20 fails on an update, I want the updates (DP_Update) to continue. I then want to somehow invalidate record 5 so that when the list goes back to the UI, the user can be notified that the update for record 5 failed.
Does the CSLA intrinsically support this behavior, or will I have to create my own mechanism to support this (ie, setting a flag / error message propertie(s) on the object and having the UI display them based on those properties being set)?
A dyanmic list might be more of what you're looking for. It treats items in the collection as root objects. It's main purpose is to save the row as you leave it in the grid.
Unfortunately I can't use that option as the user is allowed to select multiple records and make a change that applies to all of them. This would cause multiple server hits which I want to avoid.
In the interim, I'm just checking a return condition on a stored proc and setting a generic "record already updated by another user" or "record has been posted and cannot be changed" on an object property itself (UpdateStatusMessage) that can be displayed in a grid cell.
I was really hoping to add a broken rule to the object and have the record highlighted in red in the bound grid when the objects came back from an update. Unfortunately that just caused more problems than I was willing to wrestle with.
I'd be curious as to how others are handling a similar scenario.
If you are using the Transactional attribute on your root method the update transaction will only rollback if an exception is allowed to flow up from the root method.
But really, it doesn't sound like you want a transaction to protect the set of updates, rather it sounds like you want to do one update at a time, each basically being its own transaction. Since SQL invocations are ACID, each one is protected individually automatically.
In other words, it sounds to me like you can (more or less) do what you want by
If I were doing this I'd probably have each child do its own insert/update/deleteself, and that's where the try..catch would exist. That way you are in the child object when the failure occurs. I'd then have a private property to store the exception or exception message. And I'd have a business rule that is broken when this value is not null.
So when you catch an exception in the Child_Update (for example), you'd set this private DataException property and then call CheckRules to run this rule, so the object is now InValid (or at least has a warning).
You'll probably need to override IsSavable and Save to allow saving of the object when it has this error. Or have some way to clear the DataException property after the user has change the object. In short - you need some way for the object to be "valid" once the user presumably fixes the problem.
That's perfect. Overriding the IsSavable and Save() is just what i need in order to ignore the fact that the list is essentially invalid when it returns in this scenario (if the list is invalid upon return, no other changes to the list will be allowed to be saved, which is the issue i was facing earlier).
Copyright (c) Marimer LLC