From: John R. <jr...@ce...> - 2017-02-13 23:50:50
|
> On Feb 13, 2017, at 3:16 PM, Nick Hall <ni...@gr...> wrote: > > Paul, > > This doesn't work for my census editor problem. Consider the following: > > 1. Edit a census using the census (form) editor. > 2. Edit a participant of the census using the standard person editor. > 3. Enter census details for the person. > 4. Save the census. > 5. Save the person. > > The census details for the person will be lost. To avoid this we need a way to lock the census event and all its participants. I was thinking of a simple lock table. Nick, That requires you to get closer to the iron than you want, because you have to ensure that exactly one module handles all access to the lock table and that that module is protected by a mutex. Even that will fail in multi-user access because each instance of Gramps will have its own mutex. Besides, locking alone isn't sufficient. You also want transaction support so that in the census editor case either both the census *and* the person records get saved or neither gets saved, and you want foreign key constraints to prevent dangling references between the two; that applies to the event-deletion case you led off with as well. BDB and SQL provide facilities (locking, transactions, and foreign key constraints) that handle these problems safely and with much less work. Use them! Note that different database engines do locking differently. For example in BDB you can lock individual rows; in SQLite3 the lock is on the whole database, while MySQL and PostgreSQL explicitly lock tables (they'll lock rows during queries, but you don't have enough control over that process to protect every case). In the case of the census editor you also want a transaction that wraps both insert operations to make the whole thing atomic so that if writing the person. For the earlier case of deleting the event out from under the person, it could be addressed with locking but foreign key constraints will work better and more generally. Regards, John Ralls |