D19087: Add standalone conversion functions for PropertyMap to Json and vice versa

Alexander Stippich noreply at phabricator.kde.org
Sun Feb 17 19:00:54 GMT 2019


astippich added a comment.


  I was wondering if using QDataStream would be simpler, but the data size was over twice the amount compared to the size using JSON during my testing. But this would solve a lot of the limitations which JSON imposes, like handling int and doubles, qdatetime objects, and there would be no need for merging/unmerging items after fixing KFileMetaData.

INLINE COMMENTS

> propertyserializationtest.cpp:2
> +/*
> +   This file is part of the KDE Baloo project.
> + * Copyright (C) 2019  Stefan BrĂ¼ns <stefan.bruens at rwth-aachen.de>

very minor nitpick: missing * 
also below

> propertyserializationtest.cpp:102
> +    QCOMPARE(res, properties);
> +}
> +

A test with stringlists and single strings would be nice. Also doubles should be checked.

> propertydata.cpp:80
> +                propertyMap.insertMulti(prop, val.toString());
> +            }
> +

This means that multiple entries with the same key get stored as single entries in the property map, right? 
This breaks the current behavior in dolphin and baloo-widgets. Merging (or more specific D19088 <https://phabricator.kde.org/D19088>) must then wait until we convert all those data to output stringlists. But I think this code will also split up data of stringlists, doesn't it?
Also, if there are multiple extractors for the same mime type (which I know there aren not currently) , which will add e.g. two releaseYear properties, these will be converted to a string.

> propertydata.cpp:83
> +        } else if (it.value().isDouble()) {
> +            propertyMap.insertMulti(prop, it.value().toInt());
> +        } else {

I think that will break all properties containing doubles, of which there are a few.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D19087

To: bruns, #baloo, #frameworks, ngraham, poboiko, astippich
Cc: kde-frameworks-devel, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190217/acce7a69/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list