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

From Gramps
Jump to: navigation, search
(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...")
 
(Emitting signals on other instances)
 
(3 intermediate revisions by 2 users not shown)
Line 6: Line 6:
 
==What is the need?==
 
==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?
+
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===
 
===Emitting signals on other instances===
Line 13: Line 13:
  
 
* when an edit/delete/add is made, emit that signal on remote Gramps instances
 
* when an edit/delete/add is made, emit that signal on remote Gramps instances
* https://github.com/gramps-project/gramps/tree/gui-sync
+
* <del>https://github.com/gramps-project/gramps/tree/gui-sync</del>
  
 
===Row locking===
 
===Row locking===
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/ (Gramps-devel) Gramps 5.0 GUI sync proposal] - From: Doug B. - 2016-05-07 00:27:19
  
 
[[Category:GEPS|M]]
 
[[Category:GEPS|M]]

Latest revision as of 01:02, 7 December 2023

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