DBI backend and engine GObjects

[Phil Longstaff]

I just realized that as part of the DBI branch commit, I also included some code which I had merged from the gobject-engine-dev2 branch (gnc-budget and gnc-commodity).  Since, as Derek noted, this can make picking changes for back-porting to the 2.2 branch more difficult, there are some options:

1) remove the dbi checking, remove the updated GObject code for budget and commodity, then recommit
2) leave as is and understand that there are potential problems if code in gnc-budget or gnc-commodity needs to be back-ported.

Reason for moving ahead with gobjectification: for each column in the db, the sql backend needs to know how to get and set the value.  There are 3 mechanisms and are used in this order: a) a gobject parameter will be used if available, b) a qof-registered getter or setter will be used if available, and c) a custom routine is needed.  gnc-commodity had no qof-registered getters or setters, so including it as a gobject with properties allowed me to remove lots of code.  In other words, backing out this change requires me to add back a bunch of custom property getter/setter routines, but does not really change any functionality.

My preference is for #2 since that means less work for me but if the
major other developers want me to back out those changes, I will.

BTW, besides dbi support and some future features (e.g. use of foreign keys), I'm interested in moving forward with gobjectification.  To do this, I'll create a new gobject-engine-dev3 tree from trunk which will include the dbi backend.

Phil