QOF and child objects
linux at codehelp.co.uk
Tue May 3 13:08:27 EDT 2005
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
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
> 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).
> 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
> 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
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
> 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050503/020eeb82/attachment.bin
More information about the gnucash-devel