New QOF function, idea

Derek Atkins warlord at MIT.EDU
Fri Feb 11 10:12:25 EST 2005


Neil Williams <linux at> writes:

> 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. 

Having an api like:

   gboolean qof_entity_copy_to_session(QofSession* new_session, QofEntity* src);

would certainly be reasonable.

> 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.

No need to g_list_copy(); you don't need to retain the actual glist.
Also, I'd make the API on single objects; if you find you're using it
with glists a lot then you can consider adding a second API to handle

> If I was to create a function in qofid.c:
> void qof_entity_copy(GList *entity_list, QofSession *target);
> Would that be useful?

Hehe.  Looks really close to the API I suggested.  Sure, that would
work, although I still think you should have an API to handle a single
object and a second one to handle lists.

> Comments?

This is called "code refactoring".  When you find you're duplicating
code all over the place it makes perfect sense to rip out all the
copies and make a new function.  99% of the time code refactoring is a
Good Thing because it reduces the overall amount of code in the
program, and if you later need to make a change to the way it's done
you only need to change it in one place instead of three.  :)

IMHO you rarely need to ask permission to refactor code like this.  If
you have questions about what the API should look like, great, but I
think you're doing just fine.  :)

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list