version and version_check

[Neil Williams]

On Sunday 15 August 2004 4:38, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > Should version and version_check be compared/set in a merge?
>
> _maybe_.  IIRC these are used for object versioining between the
> engine and the backend.  So, I'm not sure exactly what a "merge" would
> do to them.

OK, I'll leave those alone. I can't see a situation where you'd need to 
overwrite the version of objects in the target book with objects from an 
import book - unless people want to go back in time. It probably shouldn't be 
default behaviour even if it was useful occasionally.

> > Various objects use these members in the structs, they can be merged
> > using QOF_TYPE_INT32 with no bother - question is, should they?
>
> I've never heard of QOF_TYPE_INT32.  I don't think we have one, nor do
> I think we should have one.  I can't imagine any user-servicible parts
> that are only 32-bits wide.  We've got QOF_TYPE_NUMERIC for numeric
> values and QOF_TYPE_INT64 for non-"numeric" numbers.

Isn't QOF_TYPE_INT32 useful for gint? Particularly for these enum values where 
the maximum is about 12 or for gncBillTermGetDueDays. The merge isn't just 
working on user-serviceable parts, I need to be able to set and get every 
part of each object, subject to those parameters that are calculated fields, 
otherwise some objects will be left with corrupt / incomplete parameter data.

business/business-core/gncBillTerm.h:Uses a standard gint (QOF_TYPE_INT32) to 
set the enumerator

> > I've got a complete list of current problems:
> > In the table, when the specified object is merged, data in the specified
> > struct member variables will not be read, compared or set. Existing
> > values in the target QofBook will not be changed. Where the object is QOF
> > compatible, if the object is new (MERGE_NEW) the listed variable will be
> > set to the default value given in the table.
> > http://www.codehelp.co.uk/code/problems.html#AEN378
>
> Ok, so you're still not performing any compares..  Got it.

Umm, yes, I am - the section quoted relates to the objects I can't yet merge - 
a lot of which won't be usable until gnc_commodity is fixed.

I'm already comparing and merging any object that resolves to the basic 
QOF_TYPE fundamentals. It's fine for simple QOF objects and it's ready to 
move on to complex objects that contain more than just simple strings, dates, 
integers, booleans and gnc_numerics. Which is why I'm adding a lot of 
QofSetterFunc and a few QofAccessFunc declarations to engine and business 
objects - I can't test the code until the objects are ready. Plus adding the 
essential create: declarations for QofObject - a merge isn't much use if it 
can only change existing objects, it needs to create new ones too. That's 
already working.

> > I'm working on the business objects too, making them QOF compatible and
> > I'll post another table of the business objects discrepancies on the same
> > page.
>
> "making them qof compatible"???  They should've been nearly completely
> QOF compatible..

Some were missing QofObject definitions (so they would never appear in the 
merge) and most had incomplete parameter lists.

I've added a few parameters to many objects so that each object is fully 
described to QOF - excluding those parameters like balances that are 
exclusively calculated and should not be set.

I've added more QofSetterFunc definitions where there were none, I was going 
to add a few wrappers to convert enums to gint but :

> > One solution I've used locally is to use QOF-compatible wrappers. e.g.
> > for functions that set or get enums, I'm using a gint wrapper:
> > void gncBillTermSetType_q (GncBillTerm *term, gint type)
> > {
> > 	GncBillTermType q = type;
> > 	if(!q) return;
> > 	gncBillTermSetType(term, q);
> > }
> >
> > Is this satisfactory? (Is it unnecessary?)
>
> Yes, it is not necessary.  You can pass an int into an enum.

What about the return value? If I use a get_fcn that returns a GncBillTermType 
can I rely on implicit casting to a gint or are there situations where it's 
safer to use an explicit cast, as here:

gint gncBillTermGetType_q (GncBillTerm *term)
{
	if(!term) return 0;
	return (gint)gncBillTermGetType(term);
}


-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20040815/bb1b3a07/attachment.bin