Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/395#discussion_r194444902
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java
---
@@ -668,7 +682,40 @@ private boolean isChildDoc(SolrInputDocument
extendedMap) {
return
extendedMap.containsKey(req.getSchema().getUniqueKeyField().getName());
}
- private SolrInputDocument generateExtendedValueMap(int ev) throws
IOException {
+ private boolean entryIsChildDoc(Object val) {
+ if(val instanceof List) {
+ List listVal = (List) val;
+ if (listVal.size() == 0) return false;
+ return listVal.get(0) instanceof Map;
+ }
+ return val instanceof Map;
+ }
+
+ private void safeAddValue(SolrInputDocument doc, String fieldName,
Object value) {
--- End diff --
Okay I see. Interesting -- there are clearly pros/cons to having
SolrInputDocument implement core JDK abstractions. It makes working with it
easier, though now some things like what you see here happens automatically
when we don't want it to.
There is no perfect solution here but I'd rather see
SolrInputField.addValue do an instanceof check when it sees that `v` implements
Iterable to guard against iterating the child doc. This is much
smaller/simpler than your safeAddValue, and it's something that won't be tied
to Json or any other input format. Even someone who wants to use SolrJ and
thinks that they can just call set/addValue would be surprised it doesn't work
unless we make the change at SolrInputField.
Also admittedly, this is a gotcha to the path of putting nested child docs
in values, but not a big deal.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
