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