Db structure

[Phil Longstaff]

The slots mechanism is designed for extensions.  However, it seems to me that it would be easier for an external tool to access data from "real" tables than from slots.  I am not proposing to get rid of slots, but rather that some of the information currently stored in slots should be moved into the regular tables (or in the case of the budget info, into a new table).

If some of the current information is removed from slots and moved to a new location, then saved to an XML file, the older versions of gnucash would not know how to get the information.  Older versions expect the account flags to be in slots.  If I move them to the accounts table and remove them from slots, then save a file to XML, the older version won't be able to access the flags.

Phil




________________________________
From: "marcus.wolschon at googlemail.com" <marcus.wolschon at googlemail.com>
To: Phil Longstaff <plongstaff at rogers.com>
Cc: Gnucash list <gnucash-devel at lists.gnucash.org>
Sent: Monday, August 10, 2009 9:39:23 AM
Subject: Re: Db structure

On Sun, 9 Aug 2009 15:46:46 -0400, Phil Longstaff <plongstaff at rogers.com>
wrote:
> 1) Each account stores a number of boolean flags (tax-related, hidden, 
> placeholder) in the slots table.  It would be simpler if these were just 
> boolean values in the accounts table.

I find the slots-mechanism very nice for extensions and plugins and I'm
making
extensive use of it. (e.g. mark transactions with the HBCI-transactions
they belong to, with document-IDs of receipts in a
document-management-system,...)

> 2) Each budget stores all of the budget information in slots, with path
> names 
> of <guid>/<period> (e.g. 294ddec82b0840980d98203/12).  These should be
> moved 
> to a new budget_values table with columns id (autoinc/primary key), 
> account_guid, period_num, budget_value (numeric).  This would allow
better 
> access to the budget info by external tools.

I have no preference there.


> This leads to potential backwards compatibility problems in the xml file 
> format.  However, as long as 2.4 can read 2.2 XML files, do we need to
keep
> 
> backwards compatibility so that 2.2 can read 2.4 files?

I may not be the only one to edit his gnucash-file on multiple computers
(including different versions on Linux and Windows.

What has changing the DB-schema of a not yet released version to do with
changing the establised XML-schema?

Marcus