On 09/10/2012, at 11:57, Keary Suska wrote: > This is not an easy problem, although I would say it is more of a business > logic issue than a technical one. Namely, what would be the uncommitted data > policy? Discard all changes? Or commit with a discard fallback (in case of > validation errors)? > Both approaches could lead to data integrity and customer service issues, > depending on the business logic.
I thought about this. Then I started to think about crazy "timer" ideas... And then gave up. :) > In my most recent project I opted for a "social" approach: when locks are > made they are "forever", but when another user tries to edit the locked row > the app tells them the user that locked the record, which (hopefully) > provides some action of recourse, and avoids the pitfalls I mention above. I thought about this too and I am getting more and more fond of this idea each minute... Cheers, Flavio _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
