On Mon, 2002-01-28 at 16:50, Derek Atkins wrote:
> I've been thinking a lot recently about generalizing the Query
> infrastructure.   The current Query is specifically limited to
> searching for Splits (and Transactions), and all the Query
> methods are specifically tied to the Split.  I'd like to
> propose a new Query framework that breaks down queries into
> multiple levels:

Thanks, this looks like a great start.


> 1) a set of core queriable types.  A core type provides a name and a
> query predicate function that is used to compare object types.  Core
> query types include:
> 
>         string
>         numeric
>         date
>         guid

I realize that isn't list isn't comprehensive, but we
should support all the basic kvp types, including int64
and double. Also, boolean would be good, too.


> 2) a set of gnucash objects.  These are the queriable types (things
> that you may want to search on/for in the system).  Each object
> defines its name and a list of queriable parameters, the parameter
> type (which must be a core query type), and the getter function for
> the parameter.  Queriable gnucash objects would include:
> 
>         splits
>         transactions
>         accounts?
>         entries
>         customers
>         vendors
>         jobs
>         invoices?
>         orders?
> 
> The key to this new system is plugability.  Each core type and each
> gnucash object is registered with the Query subsystem.  Users of the
> query subject then build a set of query terms and can combine them to
> run searches.
> 
> I believe that this current framework as current defined can handle
> all the existing queries except for those based on the Reconcile flag.
> I'm not sure how to cope with reconcile, yet, except perhaps to make
> each "reconcile" type its own core type (i.e. the "split-recn" type).

Or just add a 'character' type, maybe.


> The attached files are the current (incomplete) header files.  Please
> let me know what you think so far.

>From my reading of the API, it looks like each object
data member (account name, account code, etc), is registered
individually. Is that right? What about dynamic kvp data?

dave

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to