Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>> I think it's safe to ignore the kvp BINARY type. I don't think it's
>> used anywhere. It /may/ also be safe to ignore the kvp LIST type,
>> but I'm not as sure that that's never used. I'm fairly confident,
>> but not 100% sure.
>
> It may be safe to ignore them now, but do you want to keep the
> capability alive for future modifications?
I can't think of any reason to... We could always add it in later
if we need it.
> Re slot table: even if lists aren't used, there is still the hierarchy
> based on sub-frames. A row in the slot table may still need a link to
> its parent, and this can't be the guid which identifies the whole slot.
> We will need some sort of secondary key, then, to represent the links
> within the hierarchy of one complete slot. Each row in a complete slot
> would have the same guid, so that a complete slot could be deleted using
> "delete from slots where guid='...'", the top level slot would have
> parent = null and secondary_key = 0, and other rows in the slot would
> have parent = secondary_key_of_parent.
>
> Of course, if there are no lists, is there really any reason to bury a
> single slot value in a hierarchy? If lists are gone, sub-frames may be
> gone too.
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.
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".
The only question with this approach is how you model an empty KVP_FRAME
as a leaf-node in the tree.
> 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
