On Thu, 2006-02-11 at 16:14 -0500, Derek Atkins wrote: > Quoting Phil Longstaff <[EMAIL PROTECTED]>: > > > 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
