Jdurham2843 commented on a change in pull request #243:
URL: https://github.com/apache/solr/pull/243#discussion_r702334152
##########
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:
After taking some vacation time, I looked back at this, and I think my
thought process above over complicated what we're trying to do here. Instead I
think we should do the following:
1. Give `other` precedence and do `putAll`s for `fields` and `fieldLabels`.
2. Add individual `fieldName` items from `other` only if they aren't present
in `this.fieldNames`.
What do you think @cpoerschke ? The only downsides I could see would be if
the user had a `field` that they didn't want externally serializable (ie: it
doesn't have an associated `fieldName/fieldLabel`), then other could override
that. That may be fine in this case. If a user wants more fine grain control,
then they should probably just do the merge "by hand" instead of relying on
`Tuple.merge`.
--
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
