Difference between revisions of "GEPS 038: Enhanced Transaction Log"
(→References) |
|||
(9 intermediate revisions by 2 users not shown) | |||
Line 11: | Line 11: | ||
* the database is deleted on family tree closing | * the database is deleted on family tree closing | ||
* the undo/redo system is cleared when an import is performed | * the undo/redo system is cleared when an import is performed | ||
+ | |||
+ | UI of current stack: | ||
+ | |||
+ | [[Image:undoredo-before.png]] | ||
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 | + | However, the current database only stores the Gramps undo info, and doesn't store: |
− | + | # the transaction comment message | |
− | + | # what set of undo records go together as a batch | |
− | + | # 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: | ||
− | + | # a transaction comment is generated "Undo #N" | |
− | + | # all batch commits are now single entries | |
− | + | # time stamp is given the current time | |
Here is the patch for master: | 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. | 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. | ||
+ | |||
+ | [[Image:undoredo-after.png]] | ||
== Limitations == | == Limitations == | ||
− | + | # Undo/Redo is a "stack"; things undone are lost if new things are done | |
− | + | # All is lost if anything is imported into this tree | |
− | + | # 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: | ||
− | + | # 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. | |
− | + | # With patch, database keeps growing. UI could get overwhelmed with a long-edited file | |
− | + | # UI doesn't show any details (eg diff of old/new) of proposed undo/redo | |
− | + | # No user entered message (like a git commit message) | |
+ | |||
+ | == Considerations == | ||
+ | |||
+ | # What happens if the Gramps data format changes at some point? JSON format may help to mitigate some changes. | ||
− | == Enhancements == | + | == 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== | ||
− | + | # {{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:
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:
- the transaction comment message
- what set of undo records go together as a batch
- the time stamp
A patch is attached for BSDDB-based databases that allows a persistent undo/redo, except that:
- a transaction comment is generated "Undo #N"
- all batch commits are now single entries
- 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
- Undo/Redo is a "stack"; things undone are lost if new things are done
- All is lost if anything is imported into this tree
- 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:
- 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.
- With patch, database keeps growing. UI could get overwhelmed with a long-edited file
- UI doesn't show any details (eg diff of old/new) of proposed undo/redo
- No user entered message (like a git commit message)
Considerations
- What happens if the Gramps data format changes at some point? JSON format may help to mitigate some changes.
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
- 8853: Human-readable database transaction log
- File:Persistent-undo.patch.zip