Today when Bob and me were looking through the Metadata class, we saw List was used.
We were hoping that the metadata objects would be unique and we’d like them to be unique in the import-export.
We were planning to iteratively get some metadata (data elements, categories etc.) and put them together to output as DXF.
I'm sure some of them can be made sets. But I think the main reason was
that we wanted a stable order. For most of the types, this doesn't matter,
but for organisation units, we are exporting according to level. Not sure
how useful this is, since I'm currently also doing the sort before starting
a OU import.
This is also used for generating the API web-pages, so that all types are
sorted on names. Which makes paging etc more stable.
I guess you could also use a SortedSet for this.
···
On Fri, Apr 5, 2013 at 1:28 AM, Saptarshi Purkayastha <sunbiz@gmail.com>wrote:
If you are sorting it, the order of insertion and keeping it in order isn’t useful I guess.
Also, one could also use a ordered Set like LinkedHashSet or TreeSet (obviously slightly slower in operation).
Would you be open to making that change, but I think in terms of expected behavior we’d have metadata to be Collection of unique objects.
···
On Fri, Apr 5, 2013 at 1:28 AM, Saptarshi Purkayastha sunbiz@gmail.com wrote:
Is there a reason not to use a Set here instead?
I’m sure some of them can be made sets. But I think the main reason was that we wanted a stable order. For most of the types, this doesn’t matter, but for organisation units, we are exporting according to level. Not sure how useful this is, since I’m currently also doing the sort before starting a OU import.
This is also used for generating the API web-pages, so that all types are sorted on names. Which makes paging etc more stable.
I am sure one of the ordered sets will be fine. I don’t think the insertion time should be that much of a concern (maybe with 400000 orgunits …). The important thing is to ensure that we can add objects without causing duplication within the lists. We might want to consider orgunits as a special case.
···
On 6 April 2013 18:39, Saptarshi Purkayastha sunbiz@gmail.com wrote:
If you are sorting it, the order of insertion and keeping it in order isn’t useful I guess.
Also, one could also use a ordered Set like LinkedHashSet or TreeSet (obviously slightly slower in operation).
Would you be open to making that change, but I think in terms of expected behavior we’d have metadata to be Collection of unique objects.
On Fri, Apr 5, 2013 at 1:28 AM, Saptarshi Purkayastha sunbiz@gmail.com wrote:
Is there a reason not to use a Set here instead?
I’m sure some of them can be made sets. But I think the main reason was that we wanted a stable order. For most of the types, this doesn’t matter, but for organisation units, we are exporting according to level. Not sure how useful this is, since I’m currently also doing the sort before starting a OU import.
This is also used for generating the API web-pages, so that all types are sorted on names. Which makes paging etc more stable.
I am sure one of the ordered sets will be fine. I don’t think the insertion time should be that much of a concern (maybe with 400000 orgunits …). The important thing is to ensure that we can add objects without causing duplication within the lists. We might want to consider orgunits as a special case.
On 6 April 2013 18:39, Saptarshi Purkayastha sunbiz@gmail.com wrote:
If you are sorting it, the order of insertion and keeping it in order isn’t useful I guess.
Also, one could also use a ordered Set like LinkedHashSet or TreeSet (obviously slightly slower in operation).
Would you be open to making that change, but I think in terms of expected behavior we’d have metadata to be Collection of unique objects.
On Fri, Apr 5, 2013 at 1:28 AM, Saptarshi Purkayastha sunbiz@gmail.com wrote:
Is there a reason not to use a Set here instead?
I’m sure some of them can be made sets. But I think the main reason was that we wanted a stable order. For most of the types, this doesn’t matter, but for organisation units, we are exporting according to level. Not sure how useful this is, since I’m currently also doing the sort before starting a OU import.
This is also used for generating the API web-pages, so that all types are sorted on names. Which makes paging etc more stable.
But Saptarshi has a use case for downloading all the dependent structural metadata for an indicator group - the indicators, the dataelements used to calculate those indicators, the categoryoptioncombos used by those dataelements etc. So the natural approach is to traverse down, like a tree, gathering up these objects and pushing them into the collections of a Metadata object as you go. The problem is that you will then encounter the same objects multiple times so it would be handy to push them into a set rather than a list.
I am sure one of the ordered sets will be fine. I don’t think the insertion time should be that much of a concern (maybe with 400000 orgunits …). The important thing is to ensure that we can add objects without causing duplication within the lists. We might want to consider orgunits as a special case.
On 6 April 2013 18:39, Saptarshi Purkayastha sunbiz@gmail.com wrote:
If you are sorting it, the order of insertion and keeping it in order isn’t useful I guess.
Also, one could also use a ordered Set like LinkedHashSet or TreeSet (obviously slightly slower in operation).
Would you be open to making that change, but I think in terms of expected behavior we’d have metadata to be Collection of unique objects.
On Fri, Apr 5, 2013 at 1:28 AM, Saptarshi Purkayastha sunbiz@gmail.com wrote:
Is there a reason not to use a Set here instead?
I’m sure some of them can be made sets. But I think the main reason was that we wanted a stable order. For most of the types, this doesn’t matter, but for organisation units, we are exporting according to level. Not sure how useful this is, since I’m currently also doing the sort before starting a OU import.
This is also used for generating the API web-pages, so that all types are sorted on names. Which makes paging etc more stable.
