General Query Framework, a proposal

[Dave Peticolas]

--=-23MdTpI+iAD3oDu5RFkW
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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:
>=20
>         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:
>=20
>         splits
>         transactions
>         accounts?
>         entries
>         customers
>         vendors
>         jobs
>         invoices?
>         orders?
>=20
> 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.
>=20
> 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


--=-23MdTpI+iAD3oDu5RFkW
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA8Vku35effKKCmfpIRAk4kAKDPKliR++dkXnUEDo4nIiVe3F1UDwCfWyoV
PD5RmWoOlPdlVnoE3OHwiZs=
=tuIG
-----END PGP SIGNATURE-----

--=-23MdTpI+iAD3oDu5RFkW--