GEPS 042: Multi-user record locking and editing
Revision as of 11:24, 9 May 2016 by Dsblank (Created page with "This GEP looks at two issues: * better support for simultaneous multi-user editing/viewing * a reworking of our editors into View vs. Edit modes. ==What is the need?== As o...")
This GEP looks at two issues:
- better support for simultaneous multi-user editing/viewing
- a reworking of our editors into View vs. Edit modes.
What is the need?
As of Gramps 5.0, more than user can be editing a tree. How can we prevent/provide indication that two people are editing the same information? How can we show updated information?
Emitting signals on other instances
- when an edit/delete/add is made, emit that signal on remote Gramps instances
- Need to be able to lock row; sqlite (maybe others) don't have row-locking ability
- "A separate lock table would probably be better. It would only ever contain a relatively small number of lock records." - Nick
- "Actually I'd argue we should leverage the RDBMS's built-in locking. Already battle-hardened. Thread safe, etc. We'll need an adapter for each one, and well-written transactions and stored procs, but I think that's a good thing." - Gerald
Edit vs. View
- "it would be nice to separate in the GUI the notion of opening up the details of an object to view, versus planning on editing. For example, currently when you just want to see the details of a person, you have to open the data in an "editor". Clicking "Ok" will update the data (and the last changed time, regardless of whether any change was made)." - Doug