GEPS 038: Enhanced Transaction Log

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:

The system can be easily adapted so that:

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

However, the current database only stores the Gramps 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.

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)

Considerations

1. What happens if the Gramps data format changes at some point? JSON format may help to mitigate some changes.

Possible 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)
   1. storage could be XML or JSON
3. database backend agnostic
4. persistent
5. should work even after an import (copy of imported file could be put into directory and time-stamped)
6. better UI to show diff, or at least summary of commit (eg, the following records were added: I0001, I0002, ...)
7. individual changes could be cherry-picked, perhaps, with checks
8. allow user comment, eg commit message

References

1. 8853: Human-readable database transaction log
2. File:Persistent-undo.patch.zip