GC, QOF and queries

[Derek Atkins]

Quoting Daniel Espinosa <esodan at gmail.com>:

> 2006/11/2, Derek Atkins <warlord at mit.edu>:
>> 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.
>
> Why you need to load all the registers in memory? in GDA you can use a
> GdaDataModel to refer a table or a query and get the data *just* when
> you use it, I think this is better in terms of performance.

Who said anything about loading all of the registers in memory?
Please read what I wrote.  If you don't understand what I'm saying,
please ask me to define the words.  I realize that English is not your
first language, but your question here seems like a fundamental 
misunderstanding
of what I wrote.

GnuCash ABSOLUTELY only pulls in transactions when necessary.  However
the ACCOUNTS are pulled in at start time.

Actually, what it probably wants to do in the long run is pull in all the
transactions from the current period into RAM (because operating from RAM
is faster than operating from Disk)..  But not pull in transactions from
previous periods.  Then it could query over those older transactions when
necessary.

>> > 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.
>
> Using a GdaDataModel or a GdaQuery, you can directly modify the data
> in the DataBase using a begin/commit transaction (usefull in a
> multiuser enviroment), of course this could fix the *autosave* future
> request becouse you can edit a transaction and when saved it wil be
> automaticaly commit to the server/database.

You're missing a fundamental architectural design of QOF and GnuCash.
Please go study QOF and then come back here.

>> Only the final commit() should push the data out to the database.
>>
>
> GDA allows you to commit the data directly with out a "buffer" managed
> by GC and then commited when the user push the "Save Button".

So What?   GnuCash doesn't do that.

To GnuCash, GDA is JUST A DATA STORE.  I dont know how to make it more
clear.  Anything else would be a fundamental change to the way gnucash
operates and would be a MAJOR re-write of much of the gnucash source
code.  I dont think anyone wants that right now.

Incremental changes are good.

-dere

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