From f973c70e3d4a7ce8b9ebc31a89da2e1f4f3da3fe Mon Sep 17 00:00:00 2001 From: Linas Vepstas Date: Tue, 29 Sep 1998 05:45:44 +0000 Subject: [PATCH] more feature wishlist to design file git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@1237 57a11ea4-9604-0410-9ed3-97b8803252fd --- src/engine/design.txt | 65 ++++++++++++++++++++++++++++++++++++- src/engine/new-features.txt | 52 ----------------------------- 2 files changed, 64 insertions(+), 53 deletions(-) delete mode 100644 src/engine/new-features.txt diff --git a/src/engine/design.txt b/src/engine/design.txt index 1325845d98..526fc481fe 100644 --- a/src/engine/design.txt +++ b/src/engine/design.txt @@ -262,6 +262,57 @@ If the above is implemented, what date should be stored if the user toggles the recn flag a few time? The date of the last toggle? The very first date that it was recn'ed? +Automatic Backup +---------------- +The following has been implemented: + +Have (by default) xacc create a backup file +filename-timestamp.xac on every save. This will eat up some disk +space until you go back and kill the older versions, but it's +better than not realizing that the data's subtly corrupt a week +later. + +A lot of small-office/home systems do this. primarily useful as a +historical record, in case you accidentally wipe out something, and +don't spot it until later. Limited usefulness, but very nice in case +you accidentally delete an entire account. + +To a limited degree, it provides atomicity/consistency/etc at the +course-grained account-group level. + + +Transaction Processing +---------------------- +The following has been implemented: + +Introduce begin() and end() subroutines that should wrap updates +to individual splits/transactions. These should be useful for +an sql back-end, where end() would be a synonym for "commit". + + +Journal Logs +------------ +The following has been implemented; see TransLog.c for details. + +Transaction logs. The idea was that every time a transaction +was called that would cause a data update, the information that +was updated would be dumped out into an "append only" log file. + +This somewhat parallels what better database systems do to ensure +integrity; Oracle, for instance, has what is called an "archive log." +You have a copy of the database "synced up" as at some point in time, +and can apply "archive logs" to bring that old copy of the database +up to date should something go wrong to trash today's copy. + +In effect, you'd have things like + +=== 97/01/01 04:32:00 === Add Transaction ==== [whatever was added] ==== +=== 97/01/01 04:32:02 === Delete Transaction ==== [whatever was deleted] ==== + +It also is a useful debugging tool, as if you make sure that the +"log_transaction()" call starts by opening the log file, writes, and +then closes and syncs, you know what is going on with the data even if +horrible things happen to the "master" database file. Remaining Work Items @@ -274,5 +325,17 @@ To find other remaining work items in the code, grep for the string "hack alert". +Ideas for engine enhancements: +----------------------------- + 1) Have (by default) xacc immediately re-read a file after every + write, and compare the two resulting AccountGroups for equality. + + During development, this is a good idea, as it will help uncover + thinko's more quickly, instead of letting them hid for weeks or months + (as the last one did). Its not a bad self-consistency check when + monkeying with the internals, damn the performance. + + It can be removed/disabled for product versions. + -March 1998 +September 1998 diff --git a/src/engine/new-features.txt b/src/engine/new-features.txt deleted file mode 100644 index f069cfb220..0000000000 --- a/src/engine/new-features.txt +++ /dev/null @@ -1,52 +0,0 @@ - -Ideas for engine enhancements: ------------------------------ - 1) Have (by default) xacc immediately re-read a file after every - write, and compare the two resulting AccountGroups for equality. - - During development, this is a good idea, as it will help uncover - thinko's more quickly, instead of letting them hid for weeks or months - (as the last one did). Its not a bad self-consistency check when - monkeying with the internals, damn the performance. - - It can be removed/disabled for product versions. - - 2) Have (by default) xacc create a backup file - filename-timestamp.xac on every save. This will eat up some disk - space until you go back and kill the older versions, but it's - better than not realizing that the data's subtly corrupt a week - later. - - A lot of small-office/home systems do this. primarily useful as a - historical record, in case you accidentally wipe out something, and - don't spot it until later. Limited usefulness, but very nice in case - you accidentally delete an entire account. - - To a limited degree, it provides atomicity/consistency/etc at the - course-grained accountr-group level. - - 3) Introduce begin() and end() subroutines that should wrap updates - to individual splits/transactions. These should be useful for - an sql back-end, where end() would be a synonym for "commit". - - 4) Transaction logs. The idea was that every time a transaction - was called that would cause a data update, the information that - was updated would be dumped out into an "append only" log file. - - This somewhat parallels what better database systems do to ensure - integrity; Oracle, for instance, has what is called an "archive log." - You have a copy of the database "synced up" as at some point in time, - and can apply "archive logs" to bring that old copy of the database - up to date should something go wrong to trash today's copy. - - In effect, you'd have things like - - === 97/01/01 04:32:00 === Add Transaction ==== [whatever was added] ==== - === 97/01/01 04:32:02 === Delete Transaction ==== [whatever was deleted] ==== - - It also is a useful debugging tool, as if you make sure that the - "log_transaction()" call starts by opening the log file, writes, and - then closes and syncs, you know what is going on with the data even if - horrible things happen to the "master" database file. - -