ANNOUNCE: QOF the query object framework

[Derek Atkins]

linas at linas.org (Linas Vepstas) writes:

> Hi Dan,
> 
> On Sun, Jun 15, 2003 at 06:13:39PM -0700, Dan Means was heard to remark:
> > Hello..
> > 
> > So, if one wanted to volunteer to help out, what do we need to do?
> 
> Download qof-0.1.tar.gz and see if you even like the thing.  
> I just added an example program that shows how to use the query
> object.  (Derek, should I copy this example back into gnucash
> somewhere? where?)

How about src/engine/test ?

> One of the earlier steps probably has to be to clean up the naming
> conventions.  We need to hash this out on gnucash-devel at gnucash.org.
> 
> I'd like to agree on a consistent naming convention for subroutines,
> objects, tokens, etc. and slowly move to that.  For the QOF functions,
> it might even make sense to rename them with a qof prefix.  Derek?
> Anyone?  

I dont think I have a strong opinion here...  How closely are we
trying to keep QOF and GnuCash code?  As it is I think GnuCash has WAY
too many "modules" and libraries...  Adding yet another one is heading
in the wrong direction.

I don't particularly care if QOF decides to change the names.  That
way QOF and GnuCash could coexist.  Actually, unless GnuCash uses
QOF directly we probably SHOULD rename the functions in QOF.

> Something that I think would be nice to have would be a prser to
> convert from a 'QOF query language' to the actual query: e.g.
> something to parse things like
> 
> SELECT Memo from gncTransaction WHERE gncTransaction.date_posted=030303;
> 
> Or something like that.  But there are many interesting directions one
> could go in.

This is in the works (or at least in the current plans).  We already
have part of this done in Gnucash (see the current postgres backend at
src/backend/postgres/gncquery.c).  The problem is that it's not
generic, the mapping from Object Type to SQL Table is not automatic,
optimizations are sometimes necessary (where a straight conversion may
not be optimal), and the current gncquery code is very Split specific.

I know that Matthew Vanneck is in the process of re-writing the SQL,
and is planning to replace gncquery.c with a more generic version.
IMHO the table names should be equal to the GNC_ID_* strings for all
objects, and the table columns should be equal to the parameter
strings (defined in the plugin).  This would make conversion MUCH
easier.

I also plan to write an embedded-mysql backend using the same
routines, so I do want to make sure they are somewhat general...

-derek

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