QOF->GObject Plan

[Daniel Espinosa]

2006/12/22, Josh Sled <jsled at asynchronous.org>:
> On Wed, 2006-12-20 at 16:10 -0600, Daniel Espinosa wrote:
> > May is time to consider to deprecate the actual File backend and
> > construct some utilities to automaticaly convert this to a SQLite file
> > (it isn't a trivial XSLT convertion but a set of functions to get the
> > data and store it to the database using GDA).
>
> I don't know about May ... how about "when it's ready."? :)
>
>
> As discussed not too long ago on the list, you can't ignore the GUIDs in
> deference to the databases's identity datatype.  The GUIDs *are* the
> object identity, even in the database.  Alos, because of how they're
> used throughout gnucash, they need to be stable over the lifetime of the
> object.

What hapend in a multiuser enviroment? if you are using a PostgreSQL
or MySQL backend may you have a multiple concurrent access to the data
in GC then what about the GUID that is managed by a GC instance?

As I see QofQuery uses the GUIDs to find objects, but in my point to
use GdaQuery enstead, you can use directly the database's IDs; may all
this work must be done in the gda-dev version...

>
> I'm not sure why functions like KvpFrame[...]get_double wouldn't be
> implemented.  Even if they're not used, it does complete the
> interface...
>

If you see my plan, I consider to replace KvpFrame by GValue API, then
you still can use a double value but using GValue. The point is to
replace the code for KvpFrame with the GValue API and some other from
GDA (it is using GValue already)

> I'm not sure why functions like KvpValue[...]new_binary would move to
> another source file: the KVP code should encapsulate its structure, and
> I don't see how that happens if other source modules need to know about
> it.
>

You'll right, I'm thinking to create a data type derived from GType
(like in GDA's binary type) to allow store this kind of data in a
GValue. (I have helped in most of the work to port GDA to GValue)

>
> (There's probably more comments to be made, I'm heading out of town for
> the holidays ...  I'm sure others are preoccupied with the same as
> well.)
>

I'm waiting for, but consider that may I can create the GObjects
directly in the engine and/or merge most of QOF's code, this is
becouse the QOF will never be exported as API, it will be for internal
use in GC, then you don't need a library.

If some of this work is accepted I can have two branches:

1) Try to use GObject/GValue/GDA in QOF with the current 2.0.x versions

2) Re-desing most engine's objects to use directly GObject and GDA,
use GValue's API and stores directly in a database using GDA; this
work will be stored in the gda-dev branch...


> --
> ...jsled
> http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo ${a}@${b}
>
>
>


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