Jdurham2843 commented on a change in pull request #243:
URL: https://github.com/apache/solr/pull/243#discussion_r692639991



##########
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:
       No problem at all! I wasn't sure if you wanted to talk it over with 
someone else before we moved forward, so I decided to take a backseat for a 
bit. The problem made my head spin thinking about it, but I think I have some 
kind of approach that may make some kind of sense.
   
   The original `merge` method just did a `putAll`, so we could think of the 
behavior of the method still following the same principle. When I look at how 
the `Map.put` or `Map.putAll` methods work, they will overwrite the old value 
with the new. `Map` also has a merge method that takes a `BiFunction` with a 
key and value, but that may be overkill unless we wanted a separate `merge` 
method that took at `BiFunction` as well to allow flexibility. So, using the 
idea of the original "putAll merge", then I would think we just overwrite in 
such a way that `Tuple other`'s `field`s, `fieldNames`, and `fieldLabels` have 
higher precedence over the originals.
   
   For example:
   if we have a `Tuple original` where `field = 'hello'` with an associated 
`fieldName` and `fieldLabel` entry, and we have a `Tuple other` with just a 
`field = 'hello'` and no associated `fieldName`/`fieldLabel`, then we take 
`other`'s state.
   
   Which sounds like something that really needs a test! I'll start writing 
those.




-- 
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

Reply via email to