2006/10/28, Derek Atkins <[EMAIL PROTECTED]>: > Quoting Phil Longstaff <[EMAIL PROTECTED]>: > > >> Nah... Think of a KVP slot like a filesystem directory tree. Each node > >> can either be a File or a Directory. The Slot Path walks down the > >> tree (through KVP_FRAMEs) until you get down to a "file" node, a KVP_VALUE > >> of some data-type other that KVP_FRAME. Just because you don't have > >> a KVP_VALUE of type "list" doesn't mean you can't (or shouldn't) have > >> KVP_VALUE of type KVP_FRAME. > > > > Yes, but without lists, the analogy is each node being either a file or > > a directory which can contain at most 1 file or directory in it. I > > question the usefulness of all of the directory levels. > > You're taking the "no lists" too literally. A KVP_VALUE of type LIST > is effectively a File with Multiple data contents. It's NOT a directory. > A Directory (KVP Value of type KVP_VALUE_FRAME) still contains a set of > values! > > >> However... You CAN model it as a flat table! > >> Take a look at the existing PG Backend KVP implementation. You can > >> model it as: > >> > >> text(32) object_id NOT NULL, > >> text slot_path NOT NULL, > >> enum(kvp_value_types) value_type, > >> ... values > >> > >> You can construct (and deconstruct) a full kvp tree this way. No > >> need to reference parents or anything like that. The slot_path would > >> be a string like "/A/B/C/D". Each "/" implies a KVP_FRAME with "/" > >> denoting the "root node". > > > > Fine, but without lists, isn't this equivalent to adding '/' to the list > > of chars which can be put into a KVP node name? Without lists, "/A/B/C" > > and "/A/B/D" are separate independent nodes. With lists, C and D are > > children in the list "/A/B". > > Yes and no.. You can iterate over all members of a KVP_FRAME. BUT > this iteration is always done in RAM. The DB only needs to treat a > full set of slots as an atomic unit. > > So, yes, you, as the DB Backend, can think of it this way because you're > always loading and storing the full data-set atomically. In reality > it's not the case, but you can ignore reality for your purposes. > > >> The only question with this approach is how you model an empty KVP_FRAME > >> as a leaf-node in the tree. > > > > Yes, this works. By adding 'empty' to the KVP type enum (at least in > > the DB), you can model empty KVP frames. > > Okay... > > > Phil > > -derek >
Are there any point to take apart the "internal functionality" and the "DB work"? Are we thinking about to use the power of the DB in data managing? Are there a point where we can "change" the core in that way? and implement a "plugin to import 'old format'? Sorry, but I need to study some code before make sure about you're talking about but, I don't want to try to implement the GC "internal functionality" forcing the DB to that, without consider the power or problems, when you use a DB. Have you consider to implement this backend using GObject, and implement a interface to QOF to avoid re-write the entry core, but make the first steps to implement a new arquitecture in the Core. -- 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
