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

Phil Longstaff phil.longstaff at gmail.com
Tue Dec 16 14:57:24 EST 2014


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 <sdementen at 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 <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
> >
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


More information about the gnucash-devel mailing list