Looking for some background here. If you read the jira, the issue we have
is a fully numeric value for a field being looked at for enrichment is
causing an exception at enrichment time because we are using casting, and
trying to cast a Long to a String.
We support getting the value the following ways:
public Object getValue() {
return value;
}
public <T> T getValue(Class<T> clazz) {
return clazz.cast(getValue());
}
In practice, we pretty much always call this with either Map.class or
String.class.
All of the tests we have as well always use Strings. If we want a String,
based on CacheKey we cannot assume as we do the ability to cast to it, and
maybe should do getValue().toString() or something.
In METRON-567 - it looks like the parser is mapping the csv input through
grok to either strings or longs based on their composition ( I have not
gone down the rabbit hole to the grok side of this yet to confirm where the
mapping to object type is done ). So that will be a problem as well. I
think based on my current understanding that each Cache is per message
operation, and we don’t have to worry that field _a may be Long one message
and String in the next.
>From the readme.md in enrichments, there doesn’t seem to be a restriction
on the ‘type’ of a field in the enrichment mappings to String.
Any thoughts?
