Improve support for Multi-Valued properties

[GoogleCodeExporter]

Currently support for Multi-Valued properties is provided by delimiting 
individuals values with a comma. For example:

  <entry key="someMultiValuedProperty">one,two,three</entry>

But that does not allow for values that may contain a comma. For example:

  <entry key="someMultiValuedProperty">The devious, lazy red frog</entry>

is treated as two values: "The devious" and " lazy red frog". Instead of a 
single value "The devious, lazy red frog".

Possible solutions:

(a) Provide a way to nominate an alternative delimiter character. E.g. make 
that a run time parameter for the import. Or via use of <comment> element in 
the metadata file. Or via an attribute of the <entry> element. For example:

  <entry key="someMultiValuedProperty" delimiter="|">one|two|three</entry>

(b) Provide a way to escape the delimiter character.

(c) Use repeating <entry> elements with the same key to represent the 
individual values. So the first example would become:

  <entry key="someMultiValuedProperty">one</entry>
  <entry key="someMultiValuedProperty">two</entry>
  <entry key="someMultiValuedProperty">three</entry>

And the second remains as:

  <entry key="someMultiValuedProperty">The devious, lazy red frog</entry>

Original issue reported on code.google.com by michael%...@gtempaccount.com on 14 Nov 2013 at 8:57

[GoogleCodeExporter]

Note that neither option (a) nor (c) are possible: option (a) because the 
format of properties files is defined by the JDK and can't be modified / 
extended; and option (c) because the behaviour of the JDK is undefined when 
duplicate keys are found in a properties file.

Arguably the tool could introduce it's own XML (or JSON, or YAML, or ...) 
formatted files, but this is undesirable for other reasons.

Original comment by pmo...@gmail.com on 17 Nov 2013 at 6:55

• Changed state: Accepted

[GoogleCodeExporter]

Yeah - I thought that might be the case with format of the properties file. It 
does rules out use of specific attribute. And looks like <comment> elements are 
write-only via the JDK.

But I don't think that completely rules out option (a). Nomination of an 
alternative delimiter character.

A run time parameter requires no changes or additions to the metadata files. 
The user could specify the delimiter when they run the bulk importer. In the 
HTML UI it would just be an additional input value defaulting to ",".

Original comment by michael%...@gtempaccount.com on 17 Nov 2013 at 7:54

[GoogleCodeExporter]

So I figured out a better solution for this - I added another special key 
called "multiValueSeparator".  This lets you specify the string used to 
separate multi-valued properties on a per-shadow-metadata-file basis (the 
default remains a single comma character).

(note that globally overriding the default multi-valued property separator 
value has always been possible via Spring configuration - see 
https://code.google.com/p/alfresco-bulk-filesystem-import/source/browse/src/main
/java/org/alfresco/extension/bulkfilesystemimport/metadataloaders/XmlPropertiesF
ileMetadataLoader.java#109 for details).

Original comment by pmo...@gmail.com on 27 Nov 2013 at 12:09

[GoogleCodeExporter]

This issue was closed by revision bbb84f548414.

Original comment by pmo...@gmail.com on 27 Nov 2013 at 1:54

• Changed state: Fixed

[GoogleCodeExporter]

Note: the final name for the special key is "separator", not 
"multiValueSeparator".  This setting applies to both multi-valued properties 
and the "aspects" special key.

Original comment by pmo...@gmail.com on 27 Nov 2013 at 1:55