Github user mmiklavc commented on the issue: https://github.com/apache/metron/pull/995 @justinleet - Thanks for that write up - that helps considerably. Just to round out @merrimanr 's comment about polyfields: >At this point I question whether a field being a polyfield is causing this issue. The testing I've done does not support that. Javadocs for FieldType.isPolyField() state: >>A "polyField" is a FieldType that can produce more than one IndexableField instance for a single value So, from the last few examples discussed it suggests to me that being a polyfield *is* actually a problem, but it's only part of the total reason for the problem. Under the hood they are setting stored=false and docValues=false for currency and some of the other polyfields, whereas they aren't doing this for LatLonType and Point. Does that sound about right? I saw mention of Date also, and some comments about LatLonType being the only problem data type, so it would be good to summarize again what field types are specifically a problem. One bit I'm not completely clear on after the rounds of discussion is when it's desirable to return the dynamic/subfields generated by virtue of being a polyfield, and further how the doc update code is managing that differently from a normal search. For a standard doc query in context of performing an update, we don't want dynamically generated fields returned because that will bork the re-index. For a user glob query, we *do* want then returned because they may be useful to some users? Is that hovering around accurate?
---