Thoughts on architecture for the GDA backend

[Derek Atkins]

Hi,

Phil Longstaff <plongstaff at rogers.com> writes:

> 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.

So we've reached feature-parity with the 1.6 Postgres backend?
Excellent!  Definitely good progress.  What's the time frame to get
the business objects done?

> 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.

In the current GnuCash architecture this is done by having the
backend provide a framework and then having "per-backend object 
plugins" that define this persistence.

> - 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).

You get around this by performing:

  disable_backend();
  commit();
  enable_backend();

Yes, it's a pain in the butt, but it works.  The idea is to keep
yourself from recursing.

> Proposed solution:
> - convert the rest of the engine objects to be based on GObject

A definite step forward.

> - 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?

Do we really need this?  Is the current plug-in framework not
sufficient?  Or do you really believe that you can come up
with an interface that is backend agnostic?  I'd like to see
a design proposal before going along this route, because if it's
not backend agnostic then it's no better than what we currently
have.

> Phil

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available