astippich added a comment.
In D17302#410189 <https://phabricator.kde.org/D17302#410189>, @bruns wrote: > Currently, both > `Result::add(prop, "value1"); Result::add(prop, "value2");` > and > `Result::add(prop, {"value1", "value2"});` > are serialized (JSON) in the same way as `{prop: ["value1", "value2"]}` by Baloo, which is IMHO fine. This can lead to issues if e.g. two ReleaseYears are added from different extractors. That is probably impossible right now since KFileMetaData does not have multiple extractors for the same mimetype, but still. The result after deserialization is then a QVariantList with the values, and probably no client currently handles that since they expect no list. IMHO Baloo should not alter the output of KFileMetaData in any way (e.g. merging, which it currently relies on for stringlist). > On the other hand, > `Result::add(prop, "value1"); Result::add(prop, {"value2", "value3"});` > ends up as `{prop: ["value1", ["value2", "value3"] ]}`, which is nonsense, should be `{prop: ["value1", "value2", "value3"]}` I have patches ready for that and was waiting on this revision to land in order to continue... But as stated above, I also changed my mind, I do not think this is a good idea. This can happen if there are two extractors for the same mimetype. In that case, the entries may also be duplicated and merging is not a good idea. > After deserializing, we should have `KFM::Propertymap pm.values(prop)` -> `QList<QVariant<QString>>({"value1", "value2", "value3"})`. > > I am currently moving the serialization (in file/result.cpp) /deserialization (in file/file.cpp) into a separate function so it becomes testable. Anyways, the test tests how Baloo::Result _currently_ behaves. If another patch then modifies this behavior, the test should be changed when it lands. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D17302 To: astippich, #baloo, bruns Cc: kde-frameworks-devel, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams
