No file or file required ?
janssens-geert at telenet.be
Fri Dec 18 07:06:08 EST 2009
I am about to close https://bugzilla.gnome.org/show_bug.cgi?id=479581 as it is
I think the bug is still open because of the log archive it links to:
In short Derek would like to see that GnuCash can never be running in a state
where it has "no file" to back it. In the current context, a "file" means an
xml file, an sqlite file or a mysql or postgres db.
For me this is a separate issue from bug 479581, which I think should be
discussed a little further. That's why I started this thread, instead of
simply writing a new bug report.
First things first: I assume Derek's suggestion is comes based on the risk of
potential data loss when no "file" is available, yet the user can go and play
with all of GnuCash' features.
"Enforcing" a "file" to be selected from the start, or disallowing any action
if no "file" is available is one way to deal with this. In case of a db "file"
or an sqlite "file", all changes are written to the backend immediately, for
the xml "file" a separate log is kept to which all changes are written
immediately as well. So indeed, having a file available at all times helps to
prevent data loss.
Enforcing this internally is one thing, enforcing it on the user however is
another. See, users are accustomed to the paradigm that you can open a
program, create a new file (without deciding where to store it) play with it,
and only THEN decide whether or not and where to store the file.
Requiring a user to enter a storage location beforehand is counter-intuitive
in this context.
But I think these two perspectives aren't necesarily mutually exclusive.
OpenOffice.org deals with this situation rather nicely: should the program
crash before you can save your changes, you are offered to recover your
changes on the next launch of OOo. So internally OOo has saved the changes
somewhere. This location is not revealed to the user (who doesn't care about
that either), but this saved information can be recalled anyway by the program
So for GnuCash this could translate as: allow the user to have unsaved data
(start with option --nofile or as a result of the first run). In this case,
GnuCash should save the changes to a file anyway in a location that is
determined a build time (likely somewhere in a tmp directory). This log can be
in the old xml log format, but when sqlite becomes the new default file
format, making the GnuCash internal log file an sqlite file would make more
sense. Should GnuCash have to recover from a crash, it could use this internal
log for that purpose.
What do others think ?
P.S. Although I started this discussion, I'm not sure I will be the one to
implement all this, given I don't have the experience (yet). But I would like
to come to a clean design spec anyway as I didn't want Derek's suggestion to
go lost an because a clean design spec will make it easier to implement
finally, by whoever it will be.
More information about the gnucash-devel