Difference between revisions of "GEPS 038: Enhanced Transaction Log"

From Gramps
Jump to: navigation, search
(Overview)
Line 23: Line 23:
 
However, the current database only stores the lowest undo info, and doesn't store:
 
However, the current database only stores the lowest undo info, and doesn't store:
  
1. the transaction comment message
+
# the transaction comment message
2. what set of undo records go together as a batch
+
# what set of undo records go together as a batch
3. the time stamp
+
# the time stamp
  
 
A patch is attached for BSDDB-based databases that allows a persistent undo/redo, except that:
 
A patch is attached for BSDDB-based databases that allows a persistent undo/redo, except that:
  
1. a transaction comment is generated "Undo #N"
+
# a transaction comment is generated "Undo #N"
2. all batch commits are now single entries
+
# all batch commits are now single entries
3. time stamp is given the current time
+
# time stamp is given the current time
  
 
Here is the patch for master:
 
Here is the patch for master:
Line 43: Line 43:
 
== Limitations ==
 
== Limitations ==
  
1. Undo/Redo is a "stack"; things undone are lost if new things are done
+
# Undo/Redo is a "stack"; things undone are lost if new things are done
2. All is lost if anything is imported into this tree
+
# All is lost if anything is imported into this tree
3. Undo's must be done sequentially; you can't cherry-pick one change---you have to do them all (this ensures consistency, but is often not necessary for BSDDB (say, if you are just changing a field, such as name)). Other backends may need this consistency, even in a field change.
+
# Undo's must be done sequentially; you can't cherry-pick one change---you have to do them all (this ensures consistency, but is often not necessary for BSDDB (say, if you are just changing a field, such as name)). Other backends may need this consistency, even in a field change.
  
 
Also:
 
Also:
  
4. Undo/Redo is a BSDDB database; if you can't open other databases (say, due to internal file change), then you might not be able to open this. Each pickled old/new row could be a single text file.
+
# Undo/Redo is a BSDDB database; if you can't open other databases (say, due to internal file change), then you might not be able to open this. Each pickled old/new row could be a single text file.
5. With patch, database keeps growing. UI could get overwhelmed with a long-edited file
+
# With patch, database keeps growing. UI could get overwhelmed with a long-edited file
6. UI doesn't show any details (eg diff of old/new) of proposed undo/redo
+
# UI doesn't show any details (eg diff of old/new) of proposed undo/redo
7. No user entered message (like a git commit message)
+
# No user entered message (like a git commit message)
  
 
== Enhancements ==
 
== Enhancements ==
  
1. 'a routine which restores a .gramps file and applies log file. This would bring a tree up to "current".' (RonJohn)
+
# 'a routine which restores a .gramps file and applies log file. This would bring a tree up to "current".' (RonJohn)
2. store in human-readable, non-binary format (RonJohn)
+
# store in human-readable, non-binary format (RonJohn)
3. storage could be XML or JSON
+
# storage could be XML or JSON
  
 
==References==
 
==References==
  
1. https://gramps-project.org/bugs/view.php?id=8853
+
# https://gramps-project.org/bugs/view.php?id=8853
  
 
[[Category:GEPS|G]]
 
[[Category:GEPS|G]]
 
[[Category:Developers/Design]]
 
[[Category:Developers/Design]]

Revision as of 14:02, 23 August 2015

The purpose of this GEPS is to explore the implementation and functionality of an enhanced transaction log.

Overview

Currently, Gramps has a Undo/Redo system that operates as follows:

  • All database operations (except imports) are stored in a undo/redo system.
  • The system is managed by two data structures:
    • an in-memory transactions that keep track of a message, a list of record IDs, and a timestamp
    • an associated database with pickled old/new data
  • the database is deleted on family tree closing
  • the undo/redo system is cleared when an import is performed

UI of current stack:

Undoredo-before.png

The system can be easily adapted so that:

  • the database is deleted
  • the stored data can be loaded back into the undo/redo system

However, the current database only stores the lowest undo info, and doesn't store:

  1. the transaction comment message
  2. what set of undo records go together as a batch
  3. the time stamp

A patch is attached for BSDDB-based databases that allows a persistent undo/redo, except that:

  1. a transaction comment is generated "Undo #N"
  2. all batch commits are now single entries
  3. time stamp is given the current time

Here is the patch for master:

File:Persistent-undo.patch.zip

The system could easily be adapted for complete persistent undo functionality if the comment, batch set, and time stamp were also stored in the database.

Undoredo-after.png

Limitations

  1. Undo/Redo is a "stack"; things undone are lost if new things are done
  2. All is lost if anything is imported into this tree
  3. Undo's must be done sequentially; you can't cherry-pick one change---you have to do them all (this ensures consistency, but is often not necessary for BSDDB (say, if you are just changing a field, such as name)). Other backends may need this consistency, even in a field change.

Also:

  1. Undo/Redo is a BSDDB database; if you can't open other databases (say, due to internal file change), then you might not be able to open this. Each pickled old/new row could be a single text file.
  2. With patch, database keeps growing. UI could get overwhelmed with a long-edited file
  3. UI doesn't show any details (eg diff of old/new) of proposed undo/redo
  4. No user entered message (like a git commit message)

Enhancements

  1. 'a routine which restores a .gramps file and applies log file. This would bring a tree up to "current".' (RonJohn)
  2. store in human-readable, non-binary format (RonJohn)
  3. storage could be XML or JSON

References

  1. https://gramps-project.org/bugs/view.php?id=8853