GEPS 042: Multi-user record locking and editing

From Gramps
Revision as of 17:15, 9 May 2016 by Dsblank (talk | contribs) (What is the need?)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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 one user can edit a tree at any time. 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

Ideas:

Row locking

Ideas:

  • 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

Ideas:

  • "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

See also