need for KvpFrame vs "/path/for/key" in key/value store

Sébastien de Menten sdementen at gmail.com
Tue Dec 16 14:50:49 EST 2014


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


More information about the gnucash-devel mailing list