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