QOF and child objects

[Neil Williams]

On Tuesday 03 May 2005 4:21 pm, Derek Atkins wrote:
> Quoting Neil Williams <linux at codehelp.co.uk>:
> Yes, it's likely to break a LOT of places!

(thought it might!)
;-)

I hope you don't mind the request though - I had to ask.

> You should grep through the 
> code,

it's not easy to grep for a QOF parameter - it gets hidden behind 
param_getfcn(). Yes, you can call the function directly but that's not the 
point - I wasn't ever going to replace the function, just replace the 
parameter.

> but it's going to cause no end to grief in a lot of places (including 
> the reports, which makes grepping a bit more challenging).

v.true.

> It's too bad you can't "special-case" objects in QOF.  The GncOwner REALLY
> is just a placeholder, a way to store one of a set of types.

Yes, what we need is a way to bypass GncOwner from GncInvoice - to return the 
type. I'll work on that instead.

This is an important area for QOF - it's going to come up in other areas and 
it's worth solving it generically. Special cases are difficult when I'm 
trying to maintain handling that is as generic as possible.

One way I've solved this elsewhere is "wrapping" - if there is more than one 
type of object for a parameter, wrap all types in one and hide the internal 
objects completely. This would mean that there would be no separate 
GncCustomer, for example, or GncJob. I'd simply query the Owner and be done 
with it. That's OK in certain situations but I wouldn't do it in GnuCash.

I was considering wrapping GncAddress within GncCustomer etc. though. Make the 
address parameters appear as customer parameters and don't expose anything of 
GncAddress itself to QOF. Repeat for employee, vendor etc. Too much 
duplication though possibly? The same address would only appear twice if a 
user had a customer who is also an employee or vendor. Again, this is only 
changing the QofParam params[] array, not removing any of the existing 
functions.

> Perhaps 
> instead of trying to fit GncOwner into QOF, we should change QOF to handle
> superclass storage types like GncOwner?  Would that make more sense?

It would, but I agree that running queries against GncOwner as either an 
object OR a superclass is just as pointless. All that's needed is *access* 
from GncInvoice to GncCustomer/GncJob/GncEmployee etc. QOF doesn't actually 
have to know about GncOwner as long as it can access the data behind it.

It's a similar thing to AccountGroup - GncOwner is not a part of the data, 
it's part of the data handling / organisation.

I'll commit an unchanged GncOwner, modified GncBillTerm and the recursive 
copying routines in qofsession and consider things over the next few days.

This means that although the routines will work, they won't - yet - be able to 
locate the GncCustomer and thereby the Address for invoices. That will come 
later.

With AccountGroup it was easier - the AccountGroup only ever contains 
Accounts, so it was easy to bypass because the destination type was known.

> Frankly I really see no reason to turn a GncOwner into a full fledged
> object. That's REALLY stupid, IMHO.

It was worth consideration though! 
:-)

> There's no reason to make a table out 
> of them, either, because all the information in GncOwner _already exists_. 

Agreed, it's just finding it.

The invoice (or whatever else is using GncOwner) just needs to tell me what 
kind of Owner it has, as a parameter. A string is the obvious choice - use 
the e_type?

> Effectively GncOwner is just a QofEntity with a limited range of values. 

But a QofEntity is an instance, QofObject is the definition and that's the 
basis of the tables.

I've looked at changing QofObject a couple of times and each time I've found a 
better solution.

> So perhaps the right way to fix this is make a QofLimitedEntity type that
> has a limit of the types of objects and have QoF treat the LimitedEntity as
> a special type in the I/O routines?  Then we can recode GncOwner as a
> QofLimitedEntity<Customer,Vendor,Employee> (to use a C++ term).

I'll have a think on that. It looks a lot like an enum actually.

> > The rest of the changes can be internal to the object and not affect
> > existing functions.
>
> Unfortunately a lot of code assumes it can get the actual underlying guid
> from that API.

As it should, if GncOwner is going to be transparent.

> I'd have to do a LOT of research to figure out where, but a 
> number of searchparams use that API (both in C and Scheme).

It's OK, I'll take another route. 

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050503/020eeb82/attachment.bin