Entity-Relationship Diagram

[John Ralls]

On Apr 22, 2011, at 7:00 AM, Derek Atkins wrote:

> Christian Stimming <stimming at tuhh.de> writes:
> 
>> Am Freitag, 22. April 2011 schrieb John Ralls:
>>> The ERD is finally done and available for download at
>>> https://github.com/downloads/jralls/gnucash/gnucash_erd.png.
>>> 
>>> For ease of access I've added a link to it on the SQL wiki page.
>>> 
>>> One comment: It's a bit scary how much has gotten stuffed into KVP over the
>>> years. I think I found it all...
>> 
>> Thanks a lot for collecting all these relations! Indeed the KVP contains way 
>> too much stuff...
>> 
>> The "post_date" field of the Transaction is stored in two places, not (only) 
>> in KVP: It is stored directly in the object as a DATETIME field. Additionally, 
>> a year ago I added storing that date as a GDATE in the KVP, so that we can get 
>> rid of the timezone issue sometime in the future (because DATETIME is simply 
>> the wrong type for that field, 
>> https://bugzilla.gnome.org/show_bug.cgi?id=137017 ). However, the GDate kvp is 
>> currently only being set - I think it is never read anywhere, because the 
>> DATETIME field is used everywhere and I haven't gotten around to implement the 
>> actual usage code for that. Can you recognize this explanation in the code, or 
>> did I mess up my memories already?
>> 
>> Also, the two fields in Account which are stored as KVP should IMHO be moved 
>> into real fields ASAP. But indeed, currently they are stored as KVP.
> 
> The problem is that moving data from KVP to "real fields" invalidates
> the older XML files.  If you load the newer XML with an older GnuCash
> you'll lose that data.  It will fail to read it in, and then when it
> writes the file back out it wont be there.
> 
> For any data fields that we want to move we should make 2.4 aware of
> them now so then we can do the real move in 2.6.


Correct. I think we need to do a better job of decoupling the backends from the internal data structures. Part of that should be to move most of the "scrubbing" functions to the XML backend and to either make the XML backend more flexible or to have more than one, for different versions of the XML schema. (The SQL backend is already quite flexible (good job, Phil): Its schema is data-driven, albeit with compiled-in data -- but that can be fixed with a very few lines of code. ) With that decoupling, the 2.2/2.4 backends (this applies to both XML and SQL) can continue to save the former KVP fields in the KVP way and newer backends can do whatever we think is most efficient at the time.

One of the absolute worst aspects of the KVP design, BTW, is that it breaks object integrity. Instead of passing a data structure to an object as asking the object to deal with it, code all over the place gets a pointer to the top KVPFrame and has its wicked way with the contents so that the object has no idea what it has. Very naughty, indeed.

Regards,
John Ralls