GnuCash GUIDs vs. RFC 4122 UUIDs
Jeff Kletsky
gnucash at allycomm.com
Wed Feb 10 18:37:00 EST 2010
I certainly understand the desire to have an "easily touchable" storage
format, and will admit to "fixing" things in the XML that weren't easily
achievable in the UI.
On the other hand, I'm looking forward to the day that things that are
now brut-force scans of large datasets in C or Scheme to become database
queries that a good back-end store with a decent schema can optimize.
Not only do I believe that it will speed painfully slow tasks such as
the generation of reports, but also make possible helpful features such
as auto-complete instead of awkward search inputs.
XML as an import/export format? Sure, I'm behind that.Last thing I want
is to have years of books stored in a non-transferable format.
I, for one, however, am even more behind storing objects in a database
where another group of developers focus on how to quickly access the
data, provide both data and transactional integrity, and maintain an
effective backup strategy.That would leave the GNUCash team more time to
bring features to the table that we all benefit from.
On 2/10/2010 3:17 PM, Kevin Buckley wrote:
> Hopefully, a non-database backend storage format will always be maintained
> "as long as" there's a GnuCash.
>
> I have always found GnuCash to be pretty good at "doing the right thing" when I
> start coddling the XML directly and get it wrong.
>
> Long may GnuCash continue to do so without the need for having to build/install
> against a database layer.
>
More information about the gnucash-user
mailing list