KVP and data that contains a forward slash

[John Ralls]

> On 9 févr. 2016, at 08:57, Derek Atkins <warlord at MIT.EDU> wrote:
> 
> John Ralls <jralls at ceridwen.us> writes:
> 
>>> On Feb 7, 2016, at 4:03 AM, Robert Fewell <14ubobit at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> While looking at the Bayesian kvp entries and looking to convert the way
>>> they are stored based on the guid as opposed to the full account path I
>>> have come across a difference between 2.6.11 and master.
>>> 
>>> What I have done is create two basic new files, one from 2.6.11 and one
>>> from master with the account separator of / and used the CSV transaction
>>> importer to import the enclosed file once with Bayesian turned on and once
>>> with it of. If you look at the resulting kvp trees, in 2.6.11 you can have
>>> a / in a slot but master treats it as an other level, you can see this more
>>> easily in the storage of the full account path. You will also notice with
>>> Bayesian turned off, the entries stored under "desc" appear to have over
>>> written each other so you have only the last entry.
>>> 
>>> I can get around this by replacing any / with a \ for the saved Bayesian
>>> token or description and the full account path would be a guid anyway.
>>> 
>>> So the question is should the new kvp procedures allow a / in a slot or kvp
>>> path.
>>> 
>> 
>> 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. 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.

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.

Regards,
John Ralls