Simple answer is that when the sql backend was designed/written, I just duplicated the xml structure. Yes, the name could have included everything.
Phil On Tue, Dec 16, 2014 at 2:50 PM, Sébastien de Menten <sdemen...@gmail.com> wrote: > > replying to myself :-) > - in xml, the slots frame present an hierarchical structure as > <slot> > <slot:key>options</slot:key> > <slot:value type="frame"> > <slot> > <slot:key>Accounts</slot:key> > <slot:value type="frame"> > <slot> > <slot:key>Use Trading Accounts</slot:key> > <slot:value type="string">t</slot:value> > </slot> > </slot:value> > </slot> > </slot:value> > </slot> > - in sqlite, the key/value slots hold the full path to the slot like > id obj_guid name slot_type > 58 39fb62a42d731ddaa64ecd4daa764063 options 9 > 59 e51867d989899ba91314ef7c5c2e246b options/Budgeting 9 > 60 e51867d989899ba91314ef7c5c2e246b options/Accounts 9 > 61 7d781ad6895569f66447d74947e600be options/Accounts/Use Trading Accounts > 4 > > With the sqlite type of representation, one could ponder the use of the KVP > Frame object as the name includes the hierarchical relation. > > > > On Tue, Dec 16, 2014 at 8:36 PM, Sébastien de Menten <sdemen...@gmail.com> > wrote: > > > > Hello, > > > > I was wondering why there was a need for a KvpFrame type when the key was > > nevertheless holding the full path to the value, for example a Book may > > have the slot: > > > > "options" : a frame holding > > "options/Accounts" : a frame holding > > "options/Accounts/Use Trading Accounts" : a boolean > > > > If the names where just > > "options" : a frame holding > > "Accounts" : a frame holding > > "Use Trading Accounts" : a boolean > > then "options/Accounts/Use Trading Accounts" would be an hierachical path > > across several frames to end to a value. > > > > But as we have anyway > > "options/Accounts/Use Trading Accounts" : a boolean > > why do we need the frames "options" and "options/Accounts" as we already > > have the path/to/key that gives an hierarchical structure to the keys ? > > Is it due to an historical decision ? Is it still useful today ? > > > > kr > > > > sebastien > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
