Jdurham2843 commented on a change in pull request #243:
URL: https://github.com/apache/solr/pull/243#discussion_r704915217
##########
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:
That's how I interpreted `fieldNames` too. If a user starts using them
along with `fieldLabels` then they probably want more control in regards to how
they serialize things.
> would renaming in the former then also need to imply renaming in the
latter?
It could, I didn't think about that. Also..
> (It's not very "merge like" but in principle collision or overlap could
also be resolved via removal: [A B C] merged with [B D F] resulting in [A C D
F] with the common B removed but that seems quite counter-intuitive not least
how would the caller know that B was removed?)
that's an interesting idea too. However, I think if a developer wasn't aware
of the removal property, then it could be a bit of a surprise. I think in
either the removal case or the renaming case, it would create more work for a
developer versus just one method call to `Tuple.merge` ...maybe...
I think our idea of just having `Tuple.merge` do what we agreed on above and
having a user take matters into their own hands if they wanted a different
merge result would be the best offering.
--
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
