2006/12/22, Josh Sled <[EMAIL PROTECTED]>: > 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 [EMAIL PROTECTED] > > > -- Trabajar, la mejor arma para tu superación "de grano en grano, se hace la arena" (R) (entrámite, pero para los cuates: LIBRE) _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
