Commit access for trunk

[Derek Atkins]

Phil Longstaff <plongstaff at rogers.com> writes:

> 1) Add const for pointer function parameters
> 2) Add begin-edit/commit-edit function calls around multiple instances
> where values are set in an object
> 3) GObject work.  For each db field, the gda backend can get/set
> values either 1) by using a gobject parameter name 2) by getting the
> getter/setter functions registered with qof 3) by using generic
> getter/setter functions.  The order of checking which method to use is
> (1), (2) and then (3) and I am happiest using them in that order.  In
> some cases, only a getter is registered with qof even though the
> parameter can be set.
> 4) In a dialog which creates a new object, don't create the object
> until the user presses the OK.  What happens now is that the object is
> created when the dialog opens and removed if cancel is pressed or
> updated if OK is pressed.  This is a little clumsy.  It also causes
> some problems with some field definitions where I want to indicate
> that the value is not NULL.  In a scheduled transaction, for example,
> there needs to be a start date, but when it is saved because the sx is
> created when the New SX dialog is opened, the start date is NULL.
>
> Type (1) just provides extra compile-time checking and can go into trunk.

Yep.

> Type (2) reduces the number of times the backend is called to commit
> changes.  It doesn't really affect the XML backend but is not really
> GDA related - can go directly into trunk

Yep.

> Type (4) is also not directly related to gda and could go into trunk.

Yep.  Although I'll point out that gnucash does it this way because
it reuses the same dialog code for "create" and "edit".  But I suppose
within the dialog it's just as easy to test for NULL at the end as it
is to test at the beginning.

> Type (3) is not related to gda, so I don't want to introduce all of
> that code in the gda backend branch.  As far as I am concerned, it can
> go into trunk or into another branch.  If it goes into another branch,
> I would commit the change there and then merge it into gda, and leave
> it to you to merge what you want into trunk.  I assume the svn merge
> facility can keep track of all of that.

I believe it can, but you need to be careful about doing it.  The dev
branch for this gobject work would be based off a different place in
trunk than the gda-dev, so you'd need to be careful about that.  I
honestly don't know exactly how well it would work.  However, it
might.

For something like this it might make sense to go from gobject-branch
to trunk and then into gda.  The point of doing it in a branch is that
you might want to make multiple commits to checkpoint your work as
you develop, but you might break stuff in the middle.  (Small changes
are easier to audit than big changes).  But we DO want these changes
in trunk, too.

> If there is any other way you would like me to handle these kinds of
> cases, just let me know.

I think you've pretty much got it.  Keep in mind that once you have
GDA "WORKING" (even if it's not the "default" file backend, and
even if we don't have an automatic XML->GDA converter), once it's
actually working pretty well we might want to collapse down into
trunk to get wider testing.

> 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