GC, QOF and queries

[Derek Atkins]

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.

> Is this expected behaviour?  I had assumed that everything would be
> queried for.

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.

> 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.

> Phil

-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