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