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/
pgpm0ILNDgst2.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
