mdutoo
commented
8 years ago This would also allow a smarter PATCH-like / POST / merge behaviour: merging two versions of a Resource having such a set list field would mean also merging their set lists (and recursively if their items are sub-Resources) rather than merely replacing the first's by the second's. Notably useful to merge a project's (set) list of dcmp:visibleProjects.
Useful using the Import tool, so that list doesn't grow when importing twice (and when there is not a set number of items, in which case each of them could be specifically targeted using dotted paths like translations: odisp:name.0.v). However, not that useful outside import, since this doesn't happen.
Checking unicity of primitive fields is easy. For Resource types (links or embedded sub-Resources), obviously id is their URI (@id). By the way, in the case of embedded sub-Resources, obviously it would work even better with server-side auto id building (#89). Additionally, i18n should be supported as a specific case where id is the language.
Would not work for field types without defined id, i.e. maps. But the solution would be replacing maps by embedded sub-Resources - which is a good general goal (the alternative being ).
This is best done on server-side, by adding a boolean "isSet" option to DCList, and using it in ResourceEntityMapperService to parse it in a Java LinkedHashSet (preserving order) rather than a mere list. In the Import tool, a new corresponding "isSet" column must be parsed from model csv and sent along.
(it could also be done only on client side, but server-side code will be simpler, better tested and obviously more efficient)