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

From Gramps
Jump to: navigation, search
(Overview)
(References)
 
(6 intermediate revisions by 2 users not shown)
Line 18: Line 18:
 
The system can be easily adapted so that:
 
The system can be easily adapted so that:
  
* the database is deleted
+
* the database is NOT deleted on closing
 
* the stored data can be loaded back into the undo/redo system
 
* 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:
+
However, the current database only stores the Gramps 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 ==
+
== Considerations ==
  
1. 'a routine which restores a .gramps file and applies log file. This would bring a tree up to "current".' (RonJohn)
+
# What happens if the Gramps data format changes at some point? JSON format may help to mitigate some changes.
2. store in human-readable, non-binary format (RonJohn)
+
 
3. storage could be XML or JSON
+
== Possible Enhancements ==
 +
 
 +
# 'a routine which restores a .gramps file and applies log file. This would bring a tree up to "current".' (RonJohn)
 +
# store in human-readable, non-binary format (RonJohn)
 +
## storage could be XML or JSON
 +
# database backend agnostic
 +
# persistent
 +
# should work even after an import (copy of imported file could be put into directory and time-stamped)
 +
# better UI to show diff, or at least summary of commit (eg, the following records were added: I0001, I0002, ...)
 +
# individual changes could be cherry-picked, perhaps, with checks
 +
# allow user comment, eg commit message
  
 
==References==
 
==References==
  
1. https://gramps-project.org/bugs/view.php?id=8853
+
# {{bug|8853}}: Human-readable database transaction log
 +
# [[File:persistent-undo.patch.zip]]
  
 
[[Category:GEPS|G]]
 
[[Category:GEPS|G]]
 
[[Category:Developers/Design]]
 
[[Category:Developers/Design]]

Latest revision as of 22:19, 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 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.

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)

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