Jdurham2843 commented on a change in pull request #243:
URL: https://github.com/apache/solr/pull/243#discussion_r686482165
##########
File path: solr/solrj/src/java/org/apache/solr/client/solrj/io/Tuple.java
##########
@@ -87,10 +87,20 @@ public Tuple(String k1, Object v1, String k2, Object v2) {
* @param fields map containing keys and values to be copied to this tuple
*/
public Tuple(Map<String, ?> fields) {
- // TODO Use bulk putAll operation that will properly size the map
- // https://issues.apache.org/jira/browse/SOLR-15480
- for (Map.Entry<String, ?> entry : fields.entrySet()) {
- put(entry.getKey(), entry.getValue());
+ putAll(fields);
+ }
+
+ /**
+ * A copy constructor
+ * @param original Tuple that will be copied
+ */
+ public Tuple(Tuple original) {
+ this.putAll(original.fields);
+ if (original.fieldNames != null) {
+ this.fieldNames = new ArrayList<>(original.fieldNames);
+ }
+ if (original.fieldLabels != null) {
+ this.fieldLabels = new HashMap<>(original.fieldLabels);
Review comment:
I agree. I think ensuring the implementation type of the Map stays the
same, especially since `Tuple.fieldLabels` is denoted as `Map<String, String>`
to the rest of the code base, would probably be the expectation for the caller.
The same could be said for `Tuple.fieldNames` as well since its written as
`List<String>`, so a caller may not expect their implementation type to change
either.
The trouble I'm running into currently is that the implementation classes
`HashMap` and `ArrayList` both implement `Cloneable` and provide a public
`clone` method. However, the `Map` and `List` interfaces do not extend
`Cloneable` or offer a `clone` method signature and they are the only ones
that, from what I can tell, are the types we could reason about in `Tuple`. My
initial thought is to do some kind of reflection to get the constructors of the
given types and use those to instantiate the clones, but that doesn't seem
quite right to me.
```
public Tuple(Tuple original) {
this.putAll(original.fields);
if (original.fieldNames != null) {
final Class<? extends List> implementationClass =
original.fieldNames.getClass();
this.fieldNames = (List<String>)
implementationClass.getDeclaredConstructor().newInstance(original.fieldNames);
}
if (original.fieldLabels != null) {
final Class<? extends Map> implementationClass =
original.fieldLabels.getClass();
this.fieldLabels = (Map<String, String>)
implementationClass.getDeclaredConstructor().newInstance(original.fieldLabels);
}
}
```
Does that seem like the right approach, or would there be a better way to
handle this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
