Christopher Browne <[EMAIL PROTECTED]> writes:
> a) Providing the ability to write data out to random-access data
> structures (I'm thinking of prototyping something where each
> transaction establishes its own directory, and then writes data
> into a DBM file inside that directory), and then
If we're just writing one transaction per directory, then why bother
with a dbm file for the transaction? Why not use something simpler
like a text file. If you're looking for the ability to manipulate the
data by-hand, which you mentioned, this would be the clearest way.
Further, if it were me, and if I could convince myself that the
read/write performance hit wouldn't be catastrophic, I'd be tempted to
put a scheme form (or forms) in each of those per-transaction files.
I've been told that the scheme reader is quite fast, though I haven't
tested it heavily. Also note that you *don't* need to call eval here,
just read, so it's much faster than something like "load".
The fact that the directory-per-transaction approach means that we're
not going to be doing a "whole file" read/write at startup/shutdown
anymore, and that we only need to read in the transactions on-demand,
means that this approach might well be faster than the old one from
the user's perspective even if we're using guile read and write
functions (which are almost certainly slower than the current approach
when considered on a per-transaction cost basis).
We'd have to test all this, though. There are some "write time"
issues that have performance implications above and beyond the speed
of the guile "writer", but there's a good chance that they won't be
critical.
In any case, I'm not saying this is the right choice, and though I'm
kinda pro-scheme, I'm happy with something else if it's a better
solution. However, I do think this is worth at least a bit of
consideration.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
