New QOF function, idea
linux at codehelp.co.uk
Fri Feb 11 04:12:14 EST 2005
I'm thinking around partial QofBook's, QofSqlQuery, qof_book_merge and
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
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
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".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050211/ba67f693/attachment.bin
More information about the gnucash-devel