From: Paul C. <pau...@gm...> - 2017-02-13 20:25:52
|
I wonder if we might include as part of a commit, an option to validate references. If before/after the base commit they were found to be invalid, the db could refuse the commit or undo and warn user... If we ever go multi-user, this short block would have to be thread safe. We'd probably want to fix dialogs so they don't close until the commit actually succeeded, so user could try to fix things. Of course that would require yet more code to tell user what went wrong... A second (perhaps better) possibility would be to validate, and quietly remove, any invalid references. Again as part of commit code. Could then complete the commit normally and leave db consistent. This would be pretty non-invasive to everything else. Probably want to avoid the validation if running batch mode... More than this and it starts to sound like you need two phase commit strategy like used by the big multi-user dbs. Paul Culley On Mon, Feb 13, 2017 at 11:45 AM, Nick Hall <ni...@gr...> wrote: > Devs, > > I have found an easy way to create a broken link: > > 1. In an empty database, create one person with one event. > > 2. Edit the person and leave the editor open. > > 3. Switch to the event view and delete the event. > > 4. Click "OK" in the person editor. > > The editor will try to save a reference to the deleted event. In 4.2, > this may be the cause of some of our NoneType errors. In 5.0, we now > get a more descriptive HandleError. > > The problem occurs because the delete action edits an object that is > already being edited. > > At the moment, the only locking is provided by the ManagedWindow class > which prevents two editors from editing the same object. Locking is a > known issue for the census editor, which effectively edits an event and > all its participants. Editing a census participant whilst the census > editor is open can result in data not being saved. > > Multi-user access in the future will also require application level > locking. Consider two users editing the same person in two different > sessions: > > 1. User A open the person editor. > > 2. User B edits the same person and saves their changes. > > 3. User A saves their changes. > > The changes made by User B will be overwritten. > > It look like we need to consider a better locking mechanism. > > Any ideas or suggestions? > > Regards, > > > Nick. > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |