There's some misleading naming going around in relation to KeyList merging, which effectively manifests as KeyList merging not working, at least so it seems.
To start with, the KeyValueListAppender used by e.g. MergingStopPlaceImporter doesn't actually do what the name and related variables imply but only handles imported-id list merging.
There is also KeyValuesMerger which seems to do the right thing but this bit of code is used only over GraphQL when a user specifically merges stop places in UI, not as part of the import.
For the needs of the import functionality neither of these take into consideration the importType parameter. As I see it, the expected functionality for KeyValue merging could be
INITIAL Override KeyValues as is from source. Practically this is what happens already.MERGE, ID_MATCH, MATCH: add all new KeyValues, append new values for existing keys
This however leaves out override option, as it might be the intention to update an existing KeyValue's value only, and not to convert it to a list all the sudden, so some additional thinking for that might be required. Maybe the whole functionality could be useful to define through operation configurations with basic glob matching so that one could define, say, kv.merge=imported-id, kv.override=ersad.* or somesuch for the API call with sensible defaults.
In any case, at minimum the new KeyValues should be added to the updated copy.
There's some misleading naming going around in relation to KeyList merging, which effectively manifests as KeyList merging not working, at least so it seems.
To start with, the KeyValueListAppender used by e.g. MergingStopPlaceImporter doesn't actually do what the name and related variables imply but only handles
imported-idlist merging.There is also KeyValuesMerger which seems to do the right thing but this bit of code is used only over GraphQL when a user specifically merges stop places in UI, not as part of the import.
For the needs of the import functionality neither of these take into consideration the
importTypeparameter. As I see it, the expected functionality for KeyValue merging could beINITIALOverride KeyValues as is from source. Practically this is what happens already.MERGE,ID_MATCH,MATCH: add all new KeyValues, append new values for existing keysThis however leaves out override option, as it might be the intention to update an existing KeyValue's value only, and not to convert it to a list all the sudden, so some additional thinking for that might be required. Maybe the whole functionality could be useful to define through operation configurations with basic glob matching so that one could define, say,
kv.merge=imported-id, kv.override=ersad.*or somesuch for the API call with sensible defaults.In any case, at minimum the new KeyValues should be added to the updated copy.