Difference between revisions of "GEPS 042: Multi-user record locking and editing"

From Gramps
Jump to: navigation, search
(What is the need?)
(See also)
 
Line 31: Line 31:
 
==See also==
 
==See also==
  
* http://gramps.1791082.n4.nabble.com/Gramps-5-0-GUI-sync-proposal-td4675509.html
+
* https://sourceforge.net/p/gramps/mailman/message/35069938/
  
 
[[Category:GEPS|M]]
 
[[Category:GEPS|M]]

Latest revision as of 02:07, 23 June 2022

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