KVP and data that contains a forward slash
Derek Atkins
warlord at MIT.EDU
Wed Feb 10 10:41:09 EST 2016
John Ralls <jralls at ceridwen.us> writes:
>>> Thanks for catching that. We absolutely don't want to create deep
>>> keys, performance will suffer in SQL. Please file a bug so that I
>>> don't forget.
>>
>> Don't we still have a single function that parses a full key-path from a
>> single string? How would it know how to part something like:
>>
>> /foo/bar/Assets/Bank into [foo] [bar] [Assets/Bank] ??
>
> Yes, that's the problem. It's not used for matcher tokens in maint but
> is in master, and it shouldn't be.
Ah, well that would be the problem :)
> I can't off-hand think of a case
> where using a file path for a KVP key would make sense, but if there
> is then it shouldn't have that set of functions used on it either.
Originally the KVP path was supposed to be a file-system. So if there
is a desire to move away from that, then we should be explicit about it.
> Most of our existing use of nested KVP isn't necessary anyway, but
> changing it will require a new file/db version and conversion
> routines. No point in introducing new nesting though, and besides that
> would also create a file incompatibility between 2.6 and 2.8.
I would disagree; it's nice to have some nesting (certainly within the
XML framework) to make it easy to remove whole KVP subtrees. When you
view KVP as a file system then it makes total sense to have nesting, and
all the benefits that come with it.
> Regards,
> John Ralls
-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
warlord at MIT.EDU PGP key available
More information about the gnucash-devel
mailing list