SQL backend for GnuCash 2

[Phil Longstaff]

On Fri, 2006-27-10 at 12:37 -0400, Derek Atkins wrote:
> Quoting Phil Longstaff <plongstaff at rogers.com>:
> 
> > On Fri, 2006-27-10 at 11:58 -0400, Derek Atkins wrote:
> >
> >> I'm not sure what you mean by "cascade of DELETE operations".
> >> I think we CAN depend on the DB supporting transactions, but it
> >> might depend on what level of TXN support we want/need.
> >
> > With foreign keys, you can specify what should happen if a row in
> > another table is changed when the first table refers to the second one.
> > For example, we could set it up that since a transaction split refers to
> > the account it is in (foreign key), if an account is deleted, all splits
> > referring to that account are also deleted.  Or, if the account GUID is
> > changed, all splits referring to that account will have the foreign key
> > GUID changed.
> 
> Well, GnuCash already handles these cases.  It wont let you delete an
> account if there are splits in it.  Also, GUIDs cannot change, so
> that's never going to happen, either.
> 
> I.e., gnucash itself already performs all these referential tests for
> you; the DB just needs to be a pure data store.
> 

OK.  I was just giving an example.  A better one which comes to mind is
with kvp frames.  A kvp frame can be a number, string, date, list, or
subframe.  Each element of a list is in itself, a kvp frame, so there's
a hierarchy here (and Josh mentioned how bad RDBMS's are with these).
In this case, a slot can have a parent slot, either because it's a
subframe or a member of a list.  In this case, cascaded deletes help
clean things up because the members of the list or subframes can be set
to be automatically deleted when the parent is deleted.  Now, if I want
to delete a complete slot named X, I just delete the top level row in
the table, and cascaded deletes take care of the others.

Frequency specs are another example, because a compound fs can have fs's
as children.

Phil