I'm thinking around partial QofBook's, QofSqlQuery, qof_book_merge and partitioned books.
To make best use of QSF, I envisage a tool in QOF that copies an arbitrary GList of QofEntity pointers from the current QofSession to a target QofSession. The function would accept two arguments, the list and the target QofSession. Unlike qof_session_swap_data, this is a targetted copy - only those entities in the GList would be copied into the target session. In addition, if the API specifies that the target session must always be new, I could use simpler code that creates a new QofEntity* in target, assigns it the GUID of the original and copies all the parameter data. That would be logical because if the user wants to merge this data into an existing QofBook, it would be better (IMHO) for the user to *save* the data to an external file (QSF) and then import that QSF to merge it into the relevant book. This allows the copying of GnuCash data between books and if anything goes wrong, the data is retained. As this is using QSF, it's all for g2, not HEAD. Why? Well as QSF supports partial QofBook's - it has no need for an hierarchical AccountGroup - this could allow GnuCash to export any data simply by running a QofSqlQuery - which returns a GList like this. Create a new QofSession that uses QSF, run your query, pass the list (would this need to be a g_list_copy()?) to the new function and qof_session_save(), qof_session_end(). Simple - exported in XML and in a way that can be merged back into GnuCash or processed by pilot-link etc. GnuCash could then export any data that can be queried by QOF. Maybe a GncCustomer list, a gncInvoice list, a mixture of invoices, customers and accounts. All transactions that fall within a particular date period or contain a particular description or below a certain amount. Anything really, except commodities. The Chart of Accounts (as AccountGroup isn't fully defined for QOF) isn't quite as straightforward - to retain the balances, you could export it so that each account has a single transaction as an opening balance that has the value of the balance of that account in the original CoA - or at a date specified by a query. The GUID reference to the next account in the tree will be retained so a little processing and GUID matching could recover the original CoA tree for display in external programs - GnuCash would certainly be able to recover it. Thing is, I've seen comments in the code about partitioned books - (qofbackend-p.h) - but these only refer to transactions and the comments steer you to use of it in database backends for reducing the total amount of data transferred and talks of moving rather than copying. Is my idea duplicating or extending the usefulness of this partitioning? There is no particular reason why the data from a partition of a QofBook cannot be passed to the QSF backend (using an appropriate QofSession), if that is useful. If I was to create a function in qofid.c: void qof_entity_copy(GList *entity_list, QofSession *target); Would that be useful? At present, I'm implementing various versions of this code in the pilot-link and qof_book_merge and QSF backend code, i.e. it already exists. It's getting repetitive and I was considering this as a means to eliminate at least some of the duplication. At no point would the original QofEntity in the current session be modified. This would all be thanks to Derek's patience in teaching me to use function pointers! The code in question is a large chunk that contains generic get and set function pointers for every supported QOF type - getting from one entity and setting in another. In other words, it already exists (and is already duplicated - it's in QSF and qof_book_merge already - compare the two commit routines). I've now had to reimplement it in pilot-link and hence the idea - change all three to use a single function instead of each to their own. By specifying the copy as using a separate session, I'm hoping to make it clear that this is an exact copy and I'll code a check that bails out if someone tries to send the current session as target! "Error: entity cannot be copied onto itself". Comments? -- Neil Williams ============= http://www.dcglug.org.uk/ http://www.nosoftwarepatents.com/ http://sourceforge.net/projects/isbnsearch/ http://www.neil.williamsleesmill.me.uk/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
pgpAxw5241Mcn.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
