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 -- 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