GC, QOF and queries

Phil Longstaff plongstaff at rogers.com
Thu Nov 2 16:25:46 EST 2006


On Thu, 2006-02-11 at 16:14 -0500, Derek Atkins wrote:
> Quoting Phil Longstaff <plongstaff at rogers.com>:
> 
> > I have started working on a gda backend and am starting with a QofQuery
> > -> SQL translator.  I assume no one else has such a beast (there is a
> > SQL -> QofQuery translator as part of QOF.  When we get an SQL backend,
> > it won't make sense to translate SQL -> QofQuery -> SQL).  I have also
> > looked at the pattern of queries.  When GC starts, there is only one
> > query - for bills which need to be paid.  There is no query for the
> > account tree, for example.  GC must assume that session_begin loads the
> > account tree.
> 
> The PG Backend has a sample Query -> SQL converter, but it's very
> limited -- it only does Transaction (Split) searches.

OK.  I'll see if there is anything I can borrow from it.

> This is expected behavior.  Take a look at the PG Backend.  All of the
> accounts are expected to get loaded at start time.  From the business
> side, the Tax Tables and Terms are also expected to get loaded at
> start time.
> 
> Not everything gets loaded by a query.

OK

> > Secondly, I looked at the begin/commit edit behaviour when an account
> > was being created.  There was a *lot* of begin/commit activity on the
> > commodity, including some cases of begin/commit/commit.  Is this
> > expected behaviour?
> 
> Begin/Commit can be nested (and indeed SHOULD be nested, IMNSHO)..  However
> the begins and commits should be balanced.  If they are not balanced
> then that is a bug.
> 
> Only the final commit() should push the data out to the database.

There are 2 commits because, for example, gnc_commodity_commit_edit()
calls qof_commit_edit() and then qof_commit_edit_part2().
qof_commit_edit() calls the backend commit if the editlevel is 0 and the
instance is dirty.  qof_commit_edit_part2() always calls the backend
commit.

Phil



More information about the gnucash-devel mailing list