This query kills morejunk
even though it should NOT be doing so:
| makeresults | eval a="1 2" | eval b="junk" | append [| makeresults | eval b="morejunk"] | fillnull value="" | eval a=split(a," ") | mvexpand a | table a b
It works if you move the fillnull after the split. I am very aware mvexpand removes null values.
This is a bug, right? There's no way that split is meant to return null
for any STRING value it can't split, right? Because otherwise it would be effectively mean death to use split
in conjunction with mvexpand
without a fillnull
directly in between them.
Hi Nick,
Another quick update:
Engineering confirmed and is now planning to have the fix for SPL-182511 in 8.0.4+ (this can still change).
Please let me know if there is any further questions.
Maarten Hoogcarspel
Splunk Technical Support
mvexpand
OR stats count by multivalue
remove null values.
They are useful. so, I think It' not a bug.
Conversely, do you have problems removing Null?
If it is a known problem, I think fillnull
can be used.
Just as index=hoo your_field!= ""
and index= foo NOT your_field=""
are different, the treatment of NULL in Statistics and Events seems to be different.
In Events
Null means there are no fields.
In Statistics
Null means that the field has no value.
How do you think this?
| makeresults
| eval z=""
| fields z a b c
| fillnull a b c z
However, this result is...
I downvoted this post because I don't think you read the question. The entire point is that split
is converting empty strings into null values even when you use fillnull
beforehand...
I think you need to rename the "a", because you define a new by eval and the refer to the old a. Did you try | eval c=split(a, " ")?
You can eval
a field back into itself. This should not be the problem here.
Also I tried eval
ing to a new field and then mvexpand
ing that new field per your suggestion, and it is still the same issue.