Dave Peticolas wrote:
> > >
> > > How do you plan to store the data? Any ideas yet? In a separate file?
> > > Do you have to store pointers to any existing transactions? Or have you
> > > discovred a way of wedging this into the current file format (possibly
> > > slightly modified?)
> >
> > Preferably in the same file, although there are now so many files in my
> > gnucash data files directory that I suppose it doesn't really matter...
>
> Right now, you can delete everything but the main gnucash data file.
> The .xac files are backup files created each time you save. You can
> safely delete the older ones. You can also delete the .log files.
Yes, but I'm paranoid... And, I've found it useful to have those files
occasionally. However, I should go and clean up a few of the older ones.
> The budget stuff will be stored in a separate file, probably in
> scheme forms which will be fairly easy to write out and read back
> in. Storing the budget in the main file is problematic, as it
> means the main file format has to change everytime the budget
> format changes. This is a lot riskier than storing it separately.
Unless it could be encapsulated somehow, but that's going down the track of
embedded data formats, which I seem to remember were previously debunked on
this group.
I wrote a versioned portable binary file format which would have coped with
this problem quite easily to support my PhD work. It would allow one part of
the file format to be revised without doing any damage to the rest of the data.
I designed it this way because I was constantly adding features to my program,
and I *had* to maintain backward compatibility so as not to lose access to old
data sets. However, I didn't consider robustness against file corruption when I
designed it, which is an important consideration here.
The file had a directory at the front so that you could read a specific
container entry by seeking to the specified position in the file. The size of
the directory was calculated before the rest of the file was written, so that
enough space was left for it before writing the first container. After writing
all the containers, then the directory was written with all the container
offsets.
Each container had a length field, followed by the container data.
I found this scheme to be quite reliable in the face of changing file formats
and program requirements. It meant that the file reader code had to maintain
several different versions within the same source (in a switch statement), but
I could always read an old file.
Moving to this design would invalidate all of the previous work on gnucash file
formats, and is incompatible with other discussions I have seen relating to
using XML (I think?), so I would not expect it to be adopted... Text seems to
be preferred so that problems can be corrected with a text editor?
Ben.
