Uid#createTypeUids to accept a collection of ids rather than a list

[javanna]

The downside of having createTypeUids accept a list only is that if you do provide a collection nothing breaks at compile time, but you end up calling the same method that accepts an object as second argument. Renamed both methods to avoid clashes to createUidsForTypesAndId and createUidsForTypesAndIds. The latter accepts now a Collection of Objects rather than just a List.

[jpountz]

@javanna Maybe we could also rename createTypeUids to createTypeUid (removing the trailing 's') when there is a single provided ID, this would avoid having again the same issue with eg. iterables?

[javanna]

@jpountz indeed that is what I had done at first, but the plural makes sense because the uids generated are still more than one although the id provided as argument is only one (number of types * number of ids). Shall we still do it?

[jpountz]

Maybe another way to see it is that this method should not really take Object's. Since all our ids are supposed to be strings, I think onlyStringorBytesRef` could really make sense?

[javanna]

Maybe another way to see it is that this method should not really take Object's. Since all our ids are supposed to be strings, I think onlyStringorBytesRef` could really make sense?

I tend to agree, but this would be a bigger change, that has to do with these methods being called from FieldMapper#termQuery & FieldMapper#termsQuery. I went for renaming both methods, hopefully that makes it clearer.

[jpountz]

LGTM