Thoughts on architecture for the GDA backend

[Phil Longstaff]

Except for a number of bugs (and a lot of testing, and a load/save UI), 
the GDA backend basically works for the objects outside of the business 
objects.  I also want to add an audit trail for changes and version 
support to detect when a db needs to be updated to a newer version.

Some thoughts:
- the GDA backend pulls the data from the engine objects and builds an 
INSERT/UPDATE query using the values.  This requires the backend to know 
what values/types need to be persistent.
- the GDA backend pushes data from the db into the engine objects using 
the standard exposed API.  This leads to a commit which is not needed 
because the data has just been loaded.  There also, occasionally, seems 
to be some special magic that happens (e.g. convincing the Account to 
sort/provide the running balance when splits are loaded).

Proposed solution:
- convert the rest of the engine objects to be based on GObject
- create a new GObject interface which has methods for 1) getting a 
dictionary of persistent data for the object 2) getting/setting 
persistent data.  The goal would be to have the engine object and its 
class have a bigger role in defining the db table columns in order to 
better encapsulate persistence information in the engine objects.  The 
backend would then be required to transfer the persistence information 
for an object to/from the db or file.

Thoughts?

Phil