GC, QOF and queries

[Daniel Espinosa]

2006/11/3, Derek Atkins <warlord at mit.edu>:
> 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.

Derek I'm sorry if you can't admit any that his first language isn't
english and a missundertanding could occur

I'm trying to question in the best way, with out injury to any, the GC
architecture and try to HELP to have a better one.


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

I don't missing that, I have studied the QOF enough to know that is a
GObject like implementation with a kind of GInterface, where you have
to implement the methods in order to do the work like (init, dispouse,
begin transaction, commit, roll back, and so).

If QOF have a GObject like architecture, may you can create objects
where you can have methods for the GC to make his work, and allow any
to derive from them to implement a new characteristics, even if the
Backend have a GInterface (it has) you can implement the it in order
to create a new back end a a clear way (I know this way in on the
QOF's documentation); GDA has this kind of architecture in order to
allow new Providers (any) implement the API and allow to be used
inside a GDA app.

I see you don't want to help any one that doesn't have a previous
knowlege about QOF, even if he/she have some knowlege about GObject
architecture; I know that may you haven't time enough but I haven't
time to learn QOF, I prefer to learn more about GObject.

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

Is good to hear you "incremental changes are good", but I can see you
can't support to hear any discution about that.


Sorry but I don't know who you are, are you the mantainer and have you
the last word about GnuCash?

Is QOF the realy unique way to solve the GC's objectives? Can't be
moved out or GC must use it in order to work with databases?

I don't think so.

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
cuates: LIBRE)