QOF->GObject Plan

[Daniel Espinosa]

2006/12/26, Derek Atkins <warlord at mit.edu>:
> Quoting Daniel Espinosa <esodan at gmail.com>:
>
> >> 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?
>
> What about a multiuser environment?  The GUIDs are large pseudo-random
> numbers.  The liklihood of two instances of gnucash choosing the same
> GUID is 1 in 2^128.  The Earth is more likely to get hit and destroyed
> by an asteroid than two instance of gnucash choosing the same GUID.  Sot
> that's not an issue.
>
> > 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...
>
> What about the XML file backend?  You need the object ID to persist
> with the object.  Also keep in mind that Querys can be "saved" and
> used later, so again you need some persistent identifier to each object.
> Since we already HAVE a persistent identifer, we (read: YOU) should
> continue to use it.
>

Mmm...

> >> 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)
>
> One feature that KVP-frame gives you, which we DO use in gnucash, is
> the ability to iterate over all entries at a given level in the KVP
> tree.  For example, we can have KVP key names of the form:
>
>   /foo/bar/<something>
>
> and then the KVP API lets us iterate over all entries at /foo/bar.
> I don't think a pure GValue API gives us this feature, but it's
> something Gnucash requires (because it already uses it).
>

This feature could be done with a DB engine using queries and subqueries?

> >> (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.
>
> Well, we should still built it as a library.  You never know..
>

I still think that if you need a similar library could be done using
the engine llibrary with QOF merget, but that's your idea... ok...
next...

> > 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
>
> Nah, you should work off SVN Trunk, the 2.1/2.2 code base, not 2.0
>

Well ok, may too early, may to 3.0 series... I don't know...

> > 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...
>
> Actually, I think your work should be done in a different branch that
> the current gda-dev branch.  The current gda-dev branch is specifically
> to create a gda backend for the current gnucash code.  The qof/gda
> reallignment should be done in its own branch because it's a completely
> different functionality from what Mr Longstaff is working on.
>
> You and he have very different goals, so we should separate out the work
> into different branches so you dont interfere with each others' work.

Then, are you agree to "Re-desing most engine's objects to use
directly GObject and GDA, use GValue's API and stores directly in a
database using GDA"?

Targeting to 3.x series?

if your answer is not, then I'll help the work done by Phill
Longstaff, and forget this... may there's not conditions to make this
"radical" changes in GC :-(, may in the future when GDA backend is
ready...

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