QOF and child objects
Neil Williams
linux at codehelp.co.uk
Tue May 3 06:43:02 EDT 2005
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
More information about the gnucash-devel
mailing list