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

From Gramps
Jump to: navigation, search
(Overview)
(Overview)
Line 35: Line 35:
 
Here is the patch for master:
 
Here is the patch for master:
  
[[Image:persistent-undo.patch.zip]]
+
[[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.
 
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.
  
[[Media:undoredo-after.png]]
+
[[Image:undoredo-after.png]]
  
 
== Limitations ==
 
== Limitations ==

Revision as of 14:01, 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:

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. 5. 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 7. 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