Paul McNett wrote: > Ed Leafe wrote: >> On Apr 16, 2008, at 7:33 PM, Paul McNett wrote: >> >>>> To me, .save and .delete operate at the same level: you can either >>>> save, or you >>>> can delete. once you have done either, you are done. so perfectly >>>> consistent. >>> To me, .save() and .cancel() operate at the same level: you can either >>> save, or you can cancel. .new(), .delete(), and .setFieldVal() operate >>> at the same level (just like in SQL insert, delete, and update. So not >>> perfectly consistent. >> Well, you're both right. Carl is correct at the database level; Paul >> is correct at the application level. >> >> Using local data sets, we can buffer inserts and updates. We can't >> buffer deletes without some hokey system of tracking deleted PKs that >> would be a nightmare to maintain. What is really needed is a way to >> mark a form as transactional: entering it begins a transaction, and >> leaving either commits or rolls it back. We currently don't expose >> begin/commit/rollback in the bizobj to the UI, so that would have to >> be added. > > Wait a second. Can I get the behavior I want right now by calling > biz.beginTransaction() and either biz.commitTransaction() or > biz.rollbackTransaction() at the appropriate times? > > Oops, I could have sworn we exposed begin and commit in dBizobj, for the > purpose of allowing transactional control, but I don't see them now. > > Paul
Yes, i think you can handle this by doing transaction handling explicitly. I for myself don't feel the need to go so far. Currently i just ask the user if he is sure to delete the record, but i'm handling parent/child deletes in my own transaction context because i'm using stricter integrity rules in my dbs. These stricter rules can't be handled by Dabo. Dabo does child deletes after the parent delete, which is wrong if you use strict referential intergrity. Keep in mind that doing explicit transaction handling like you want it to behave results in very long running transactions, which is a very bad thing in a multiuser environment. I wouldn't risk the implication of getting stuck because users are able to lock other users records. Uwe _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
