first draft of a merge rule set

[Derek Atkins]

Hi,

I'll try to keep my comments high level as best as possible..

Neil Williams <linux at codehelp.co.uk> writes:

[snip]
> http://www.codehelp.co.uk/code/index.html

I haven't looked here, yet.  I presume there's more info at this
website, but frankly I've been dealing with a broken machine all
week.

> The manpages for g_merge, qofbook and gncinvoice are more for my own reference 
> than anything else, although I have put some comments in some files.

g_merge sounds like a glib function.  This should either be 'qof_merge'
or 'gnc_merge', depending on where it lives and how general it is.

> // The Primitives
> #define GMCHAR			1
> #define GMINT			2
> #define GMFLOAT			3
> #define GMDOUBLE		4
> // First level compound / customised
> #define GMSTRING		10 // char*
> #define GMGBOOLEAN		11
> #define GMGINT			12
> #define GMGINT16		13
> #define GMGINT64		14

UGG!  Why are you doing this?  The objects are all pluggable _for a
reason_.  PLEASE PLEASE PLEASE use the plug-in modules instead of a
bunch of #defines.  If you have a #define it makes it VERY hard for a
plug-in module to insert a new data type.

> // Second level compound - objects that can still be resolved to a single 
> primitive
> #define GMGNC_QUOTE_SOURCE	100
> ....
> // Third level - objects that contain more than one primitive.
> #define GMGNC_COMMODITY		1000

Again, I'm not sure you really need to do this.  Can't you just add to
the object definitions?

> 	Compound objects are then further defined in terms of their component 
> primitives.
> 	Note that gnc_commodity is not complete in this example - it has been 
> shortened to allow easier testing. The create_rule adds the details of each
> field in the compound object to the rule set for that object. 
>
> #define GMGNC_COMMODITY_FIELDS(x) {		\
> 	create_rule(x, "fullname", GMSTRING); 	\
> 	create_rule(x, "namespace", GMSTRING);	\
> 	create_rule(x, "mnemonic", GMSTRING); 	\
> 	create_rule(x, "printname", GMSTRING);	\
> 	create_rule(x, "exchange_code", GMSTRING); \
> 	create_rule(x, "fraction", GMINT); 	\
> 	create_rule(x, "unique_name", GMSTRING); 	\
> 	create_rule(x, "mark", GMGINT16); 		\
> 	create_rule(x, "quote_flag", GMGBOOLEAN); 	\
> 	create_rule(x, "quote_source", GMGNC_QUOTE_SOURCE); }
>
> So far, a routine is working to assemble these rule sets into a workable 
> structure. 

This is looking AWFULLY similar to the qof-object definitions.

Frankly, the _LAST_ thing we need is _yet another_ place where an
object needs to be defined.  Can we try to centralize this as much
as possible?

We already need to re-define objects multiple times (C struct,
QofObject, XML Schema, and SQL Schema)..  I know Linas is trying to
keep this down to two (C struct and QofObject) and then derive the
XML/SQL Schema from the QofObject..  I'd personally rather continue
along that path and extend QofObject to meet your needs:

  QofMergeResult qof_object_merge_compare(QofInstance*, QofInstance*);

> Next stage is to get the data into the same structures as the rules,
> then the comparison functions can start.

I hope the comparison functions are based in the core objects???

-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