GObject in GC implementation Plan

[Daniel Espinosa]

2007/4/13, Derek Atkins <warlord at mit.edu>:
> "Daniel Espinosa" <esodan at gmail.com> writes:
>
> >> Well, it's a lot less than what you did..  And the tree continues to
> >> work build and actually work.  THAT was the goal for step 1.  Get the
> >> initialization moved over and GET IT WORKING.  Your branch still
> >> doesn't compile, let alone work.  The reason it fails: you tried to do
> >> too much at once.  Not only did you move the base initialization, you
> >> tried to move the init/dispose/finalize code and add properties all at
> >> once, instead of doing each step separately.
> >>
> >
> > That's why I started a new branch.
>
> Sure, but branches are cheap.  I'd rather have 10 branches
> that each get merged in after a week or two than a single
> branch that has so many changes that merging takes a month.
> Moreover, your commits were all huge.  Take a look at e.g.
> http://svn.gnucash.org/trac/changeset/15778 for an example of
> a small commit.  Even a single-functional-change changeset like
> http://svn.gnucash.org/trac/changeset/15773 is probably too big,
> but at least it's limited to a single functional change.
>
> Your commits were all huge (more like 15773 than 15778) AND
> multi-functional...  Making them hard to audit.
>
> Moreover, you were doing way too much at once.  You were making too
> many functional changes at one time, what with QofEntity->QofInstance,
> GObjectification, properties, signals, and changing the Qof type
> system all at once...  Too much together.
>
> Branches are cheap.  Let's make separate branches for each of the
> "major" functional changes, and keep them to ONLY those functional
> changes.
>

I agree.

> [snip]
> > I can understand why you feel that; the reason is that I don't think
> > that convert QOF to GObject will be a good idea because its
> > implementation doesn't allow it, you'll never have a full GObject
> > system if you insist to use QOF.
>
> Well, I don't think it's neccessarily a problem if we don't
> have a full GObject system.  We do want to use the features
> of GObject that make sense, but there's no reason to use them
> just because they exist.
>

I agree. If we don't need it, don't use it. If we don't find usefull,
don't use it.

> [snip]
> > Have you merged with trunk? I want to test a build, see the code and
> > help when needed.
>
> Yes, I merged gobject-engine-dev-warlord into trunk in r15846 on April 7.
>

Cool!

> [snip]
> > Phil is creating a backend, using QOF as is.
>
> Correct.
>
> > Maybe GnuCash doesn't need GDA at all, except for a backend, but if
> > you want to access the data in GC you have a library, called actually
> > Engine, but if we can create an "standard" interface using GDA, this
> > will allow:
>
> I think your first sentence hits it on the head.  I don't think
> GnuCash needs GDA at all, except for a backend.
>
> Gnucash HAS a data access library, the Engine, and anyone could use
> that to access the GnuCash data.
>

GDA is used in a lot of projects and becouse is easy to extend, more
and more is using it to access data even if the data is stored in a
database server or not (XML is an example).

GDA could allow to have multiple simultaneos access, using the
features in the database server, create power full queries not allowed
in QofQuery or even create cumples "SELECT" commands to get data
filtered, far complex than the Reports can today; all using a simple
interface: GdaDataModel.

> > - Get access from Gnumeric, to create powerfull analisys of the data
>
> Nobody has asked for this.

Yes! ME; I want to do so.

>
> > - Data interchange with other applications
>
> Okay, there has been some call for this, but we dont need GDA for it.
> We can do this as-is using the existing APIs.
>
> > - Import and export data using a CVS file, XML (like QSF does), in a
> > standard way (some other software are using GDA today)
>
> I presume you mean "CSV" and not "CVS"..  "Comma Separated Values".
> Again, I dont think we need GDA specifically for this, and even
> if we did want to use GDA, just having a GDA Backend is sufficient
> to do this.
>
> > - Easy data insert/update from other applications, like applets
>
> Nobody has asked for this, and I dont see a major value in this.
> Besides, an applet could still just call the current GnuCash API
> to perform this functionality.  There's no need to use GDA for this.
>

Yes ME!

Again GDA is more popular and easy to use, with a clear API and easy
to extend becouse it is based in GObject from the biginning; I think
GDA will become the standard way to access data sources in the GNU
project.


> > Of course that the GDA interface *must* use all the GC procedures to
> > ensure the data integrity and consistency.
>
> Or the other way around...  Plugging in GDA UNDER gnucash as opposed
> to putting GDA on top.
>

Sorry but I don't understand your "UNDER" concept.

If you mean: "Make GC use GDA in its internal procedures, and expose
an API that hides GDA", thats I'm trying to do.

For example:

QofBook holds one HashTable for each object type, this is equivalent
to have a Table in a Database; GDA has a GdaDataModelHash object that
implement GdaDataModel interface, then you can call:

GdaDataModel* qof_book_get_data_model (QofBook* book, QofType type);

and the GC's API could expose:

GdaDataModel* gnc_engine_get_accounts (GncEngine* engine);

Now you can use the GdaDataModel with any GdaQuery object,
import/export, updater, insert and so on.

Becouse GdaDataModel is an interface, in the implementation we must be
sure to call the QOF/GC internals procedures to ensure data
consistency.


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