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