GC, QOF and queries

[Daniel Espinosa]

2006/11/3, Derek Atkins <warlord at mit.edu>:
> Quoting Daniel Espinosa <esodan at gmail.com>:
>
> > 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.
>
> The steps towards a better architecture are:
>
> 1) Convert QOF to use GObject natively instead of being GObject-like
> 2) Using the same QOF APIs, try to use GDA natively inside QOF
> 3) Consider moving more information into QOF.
>
> However, in the short term, major architectural changes aren't on the table.

I'll try to joint to the QOF mailing team and try to help in this issues.

>
> >> > 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).
>
> This is true, QOF is gobject-like....
>
> > 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.
>
> Yes, but it's still just the backend.. The front end isn't changing.
> GnuCash is still buffering the data (through QOF).   QOF is just a
> framework; the objects themselves are still cached in RAM, and implemented
> by GnuCash.  QOF just provides the framework to hold it all together
> and Query over those objects.

I have some work about the implementation of GDA using a code from
Chis, and yes I'd used QOF and try to implement most of the
interfaces, but becouse I don't understand most of GC I couldn't find
who to work with the parameters sended when the function is called by
GC, even that, I want to finish the definition of the database schema
to find out later how to implement in the begin_session function using
just GDA.

>
> But as you can see from other email, I'm open to listen.  Chris convinced me
> that we should look forward to GDA-2 (through 1.99) instead of keeping
> with 1.9

I can help here!,  I was working for about 1 year in GDA 1.9x.x
development process, basicaly in this areas:

- Porting the GdaValue to GValue
- Creation of Convenient functions to easy use of GDA
- Fix compilations problems for the C# bindings (I'm not a C#
programer, just find the way to fix them)
- I have a work to make GnomeDB work in Glade3 (mostly finished)
- I have to modify some GnomeDB widgets in order to work well in
Glade3, and fixed some issues

I know some about GObject architecture, I plan to use this to
understand QOF, that's the easy part, and plan to implement most of
the Interface to create the backend privider independient as far as I
could, focus on SQLite for the first time and PosgreSQL in parallel.

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