GnuCash GUIDs vs. RFC 4122 UUIDs

[Robert Fleming]

On Tue, Feb 9, 2010 at 6:16 AM, Derek Atkins <warlord at mit.edu> wrote:

> > I have my GnuCash data in a PostgreSQL database, using GnuCash 2.3.8.
>  I'm
> > writing/using external programs (Python) to manipulate the data,
> including
> > inserting new data.  It is cumbersome for that software to invoke
> > gnucash-make-guids to make the new GUIDs.
> >
> > Do you think there would be any risk if my programs used RFC 4122 UUIDs
> > instead?  I presume not, because even if there were a collision, data
> > integrity would be preserved by the PRIMARY KEY constraints on each
> table.
>
> You have a 1 in 2^128 chance of picking the same UUID.  However, note
> that we do NOT support you adding data to the database, and you are
> likely to cause the data to become "invalid" in GnuCash's eyes.  YMMV,
> but you have been warned.  If gnucash fails to read your data or gives
> you bogus results it's your own fault ;)
>

Thanks for your answer.  There are also less-than-random UUIDs (per the
RFC), so I just thought I'd double check.  2^126 might have been too risky
for me :)

Yeah, I appreciate that I am taking data integrity into my own hands.  I
wish GnuCash would lean on the database a little more to guarantee
integrity, such as by using FOREIGN KEY and other constraints, but I
understand that as long as the XML backend is also supported, such integrity
must (also) be maintained at the application level.

Regards,
Robert

P.S. FWIW, what I'm doing is using separate tables in the gnucash database
(but in a separate schema) to catalog documents (receipts, paystubs, etc.),
and then tying those documents to transactions via the transactions' GUID.
Then I use the GnuCash front-end to import my checking account data, but for
instance, my salary transactions import as 2-split transactions (one for the
checking account, one for the income account) that need to be turned into
7-split transactions to record federal+state income tax, soc. security,
401k, etc.  I've fallen years behind on that task, so I've written a
web-based front end specifically to accelerate this task by displaying the
real paystub and computing proposed splits.

I also have a simple web form for quickly and remotely submitting new
transactions, e.g. the lunch I just had.  I think it would be great if
GnuCash would move in the direction of allowing this type of extension.
Imagine an iPhone/Android app for remote access to one's data.

I'm also planning on tying in my heap of old e-mails to my big database.
 GnuCash's open-source nature puts it in a better position than, say,
Quicken, to be able to integrate with one's other data in this way.