New QOF function, idea

[Neil Williams]

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

-------------- 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/20050211/ba67f693/attachment.bin