QOF and child objects

[Neil Williams]

Some GnuCash objects, like GncAddress, are child objects - they belong to 
another object. In effect, an address is just a building - to make it useful 
to GnuCash, it needs to be tied to a person. After all, you cannot
invoice a building, you invoice a person / body corporate working / living in 
the building.

However, this causes problems for QOF as it currently has no implementation 
for second-tier objects and I don't think it actually needs one. You cannot, 
for example, have a database table that is a child of another table - you can 
impose such a hierarchy in the code handling the tables but the tables 
themselves, as they exist on the filesystem and within the database manager, 
exist on the same level.

QOF does handle parent<->child relationships - via references and partial 
books - but in order to restore such a relationship, BOTH parties must be 
exported as genuine entities. The backend can then identify the relevant 
parent or child using the GUID and e_type stored in the reference. i.e. the 
parent-child relationship is actually considered as a pair of equals - the 
application imposes the hierarchy later. QOF pairs up the references, the 
application then imposes rules for which side of the pair is the parent.

To QOF, an address is a valid object - the building / location exists and can 
be identified as an entity. There is no real reason not to allow a user to 
query for all addresses within a city, as long as the customers at those 
addresses can be identified from the entities returned. In order for QOF to 
query an address intuitively, the address needs to exist as an entity in it's 
own right - it must be a table of it's own, with it's own records and 
structure. Changing that could make queries much harder to understand.

I have been trying to create a recursive export routine that when given a 
GncInvoice will also export the GncOwner, the GncCustomer, the GncBillTerm 
and the GncAddress. The owner is required because the Invoice only contains a 
reference to the owner, which in turn references the customer which in turn 
references the address. Circular references are handled by preventing the 
copying of the same entity twice.

To get this working, I've made GncAddress into a full QOF entity that can be 
exported as it is, including a new Owner parameter that exports the GUID (via 
QofEntity*) of the GncOwner which in turn indicates the customer. Having the 
GncOwner then allows a query that identifies invoices for this customer - 
without requiring any calls that are specific to GnuCash.

This allows child objects to be used in applications without restricting the 
ability of QOF to query, import, merge and export all entities as equals.

I'm testing now, but providing the rest of the GnuCash handling is unchanged, 
is there a problem with keeping QOF as a "collection of equals"?

-- 

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/9a34d210/attachment.bin