Would it be better to not delete the Job, but instead mark it isDeleted=true. then you have the best of both worlds? You could also ask the system, Show me all the deleted Jobs.
Doesn’t it also imply that you could have 10 users delete the same stale data on their screen, with no badness. So what if 10 users mark a record isDeleted=true.
I understand in the olden days, you wanted to remove ‘deleted’ Jobs for the disk space. But that’s not true anymore.
JMHO
Ted
On Dec 3, 2015, at 5:25 AM, Paul Hoadley < email@hidden> wrote:
Hello,
This issue has come up on the list a few times over the years, and I’ve pieced together a workable solution. This post is just to see if anyone can suggest a better one.
I have an ERXWORepetition that loops over the displayedObjects() of a WODisplayGroup. The objects are Job EOs, and within the loop there’s a hyperlink that allows a user to delete the selected Job. (You can see where this is leading.) At some point, users A and B both hit the Jobs list page which displays Jobs J1, J2, J3. User A deletes J1. User B is still on the same list page, and deletes J1—except, obviously, J1 has already been deleted, and the application silently deletes J2 instead.
Setting er.extensions.ERXWORepetition.checkHashCodes=true in Properties and binding the ERXWORepetition’s notFoundMarker to a null-valued variable in the component is a pretty good workaround: now, in the action method, if the item variable is null, I know the selected Job was not found, and I can display an informational message.
Is that the best I can do? In this slightly abridged scenario, the Job got deleted, and that was the only action available, so the informational message can say “The selected Job was already deleted”. But all I really know is that the Job is no longer where it once was in displayedObjects()—right? Say it just got moved by that action method above—is there any way to retrieve J1 when user B hits that method? (I’m not convinced you’d want that in every case, or even many cases, because the selection has been made based on stale data in front of user B. Let’s just consider this a thought experiment.)
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|