Quoting Daniel Espinosa <[EMAIL PROTECTED]>:
>> 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.
>> 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).
>> (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..
> 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
> 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.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
