Re: GnuCash page on GO site
- From: Rodrigo Moya <rodrigo gnome-db org>
- To: Linas Vepstas <linas linas org>
- Cc: Charles Goodwin <charlie xwt org>, gnucash-devel gnucash org, Gnome Office <gnome-office-list gnome org>, andru treshna com, dru treshna com
- Subject: Re: GnuCash page on GO site
- Date: Mon, 01 Mar 2004 18:23:26 +0100
On Mon, 2004-03-01 at 10:06 -0600, Linas Vepstas wrote:
> On Mon, Mar 01, 2004 at 10:37:03AM +0100, Rodrigo Moya was heard to remark:
> > > For the gnucash engine, we implemented
> > > 'qof' to solve that need. Actually, qof is older than gnomedb,
> > > Derek's re-write of qof is now the 3rd rewrite of the query engine.
> > > I don't think libgda even *has* a query engine.
> > >
> > what do you mean by a 'query engine'?
>
> To generate reports, we need the ability to perform queries
> over objects. For example, we need to find all objects of type
> "split" between a start date and an end date, which belong to
> account XYZ; this query is used to generate the checkbook register.
>
> Another example: we need to find all objects of type "split",
> for any date, that are not marked reconciled, and belong to
> account XYZ. We use this to populate the reconcile window.
>
> The query engine is *not* SQL, and it doesn't go to a database;
> rather, it traverses a set of C language objects in system RAM.
> There is a hello-world example included with the source code
> in http://qof.sourceforge.net/ Oddly, that example is not on
> the website :-(
>
right, that's what GdaSelect does. It does use SQL, but that's just for
convenience, since all the parsing and selection of data is done on the
client side, without calling the db server. That is, you create a
GdaSelect object, add to it different data models obtained from the data
source (one for each table, for instance), and then, on the client side,
you can do SQL queries over the data. All data is in memory, and on the
client side.
We need a better support for the SQL parsing code in GdaSelect though,
but that shouldn't be too hard. Thus, we could have a special syntax in
that SQL to allow for callback functions to be called, for instance, so
that you can do the calculations you talk about. Or even add special
fields to the data models to allow that. Or, as I said before, do all
that on the provider-level, so that the client just has to query the
data.
cheers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]