External Program

[John Ralls]

> On Jun 11, 2016, at 8:45 AM, Adrien Monteleone <adrien.monteleone at gmail.com> wrote:
> 
> Yep, that simple. At least from what I see here in the docs:  http://svn.gnucash.org/docs/head/group__GncGUID.html, If that link doesn't post then do a search on "GnuCash GUID" and it should be the second or so result titled 'GnuCash: GUID' as a link to the SVN docs.  Also, check out guid.cpp in the source. (in case you can't find that page, which is essentially the source documentation.)
> 
> Personally I would feel better about them being unique to the transaction if a timestamp and maybe the relevant accounts and books were used as seeds. If you do that search you will also come across a 'Design Issues' partial document lamenting the problem with uniqueness in the case of backup copies and future editing. I would think constructing the ID to be based off of books, accounts, and other info in the transaction, along with a time stamp, and THEN add a random component would be a more robust solution, but probably somewhat complicated. Perhaps a hash of the transaction info or a combination of hash and random number would be easier.

UUIDs are a very widely used standard with plenty of academic horsepower behind them: https://en.wikipedia.org/wiki/Uuid.

Note that the release branch ("maint") has a hand-rolled GUID generator and that the author had some problems getting properly unique identifiers, which is the reason for the comments you saw in src/docs/Design Issues. Aaron replaced that implementation with boost::uuid::random_generator for master. It uses a modern crypto-grade random number generator to create "version 4" UUIDs. The likelihood of a single duplication in a single GnuCash database is on the order of 10^-24. Consuming bits with hashes of static information as you propose reduces the randomness and therefor increases the likelihood of duplicates.

Regards,
John Ralls