Welcome back

[Linas Vepstas]

cc'ing gnucash-devel,

On Mon, Aug 16, 2004 at 08:27:18PM +0100, Neil Williams was heard to remark:
> Hi Linas,
> 
> Glad to see you back on the lists, hope your break was relaxing.

Thank you, it was, but unfortunately, just an eye-blink.

> Just an update, I've got qof_book_merge working with simple QOF objects (ones 
> that resolve only to fundamental QOF types) and I'm now putting in links to 
> more complex objects to provide support for compound objects. As long as all 
> objects are registered with QOF, I will be able to merge the data by storing 
> the GUID of the linked object and using that in the comparison and merge. 

Note that currently, gnc-commodity doesn't use guid's, it uses 
a char * get_unique_name().  There's pro's and con's to this,
you've bumped into one of the cons.  I haven't thought much about
whether the core qof object system should provide support for unique 
id's that are not guid's.   

--- pricedb also acts wacky.

> I've submitted a patch that increases the coverage of QofSetterFunc 
> definitions across the engine and business objects and there's a summary of 

I thought this was applied before I left?

> outstanding issues here:
> http://www.codehelp.co.uk/code/problems.html#AEN378

Ah, indeed.
-- gains_split: don't worry about that; its recomputed/deleted/added
   automatically during 'scrub'.
-- account-group: shouldn't be an issue, since each account can 
   identify its parent by guid, so you just hunt for that guid, 
   and add-to-parent.   Err, ahh, hmm. I see the issue now: there
   is no generic qof 'add-to-parent' routine, is there ... 

-- split-list, lot-list.  .. interesting ... 

I think you might be able to work around many/most of these issues
(such as the commodity issue, the account group issue, the split/lot
lists, and maybe even the sched xaction issues) by adding a "book_merge" 
routine to qofobject.h, and then letting each object implement its 
own merge routine to 'do the right thing' for that object type.  For
us 'lazy' object developers, provide a generic merge routine that 
we can use if an object is fully qof compliant.

> What do you think about the discussion between Derek and myself about QOF and 
> enums? Is it worth creating a QOF_TYPE_ENUM or should QOF_TYPE_INT32 be 
> sufficient for get_ and set_ of enums?

I'm still plowing through my emails.  If anything, I want to make the 
qof types be more and more like the glib-gobject types, and I think 
those don't have an enum.

There shouldn't be any problems working with the numeric values of
enums.

> Plus, I promise not to mess up QOF CVS - could you add me to the list of 
> developers for QOF on SourceForge, please? I'll test and build everything 
> before a commit and I'll only change any files outside qof_book_merge to 
> tweak the documentation, not to change the code.

OK, I'm still jet lagged.  What's you sourceforge id?

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933