Assuming I'm not completely incorrect, I don't believe there is a way to store a field as a boolean value. There are a few types built into the splunk parser, including string, number, and most relevantly bool, but If I attempt to assign a bool to a field, I get an error.
I'm trying to understand why assigning a bool is forbidden, if there is a programmatic limitation to handling bools or if it's being discouraged because the developers thought that it was some sort of 'code smell' to have Boolean fields. I'd also like to know what the recommended approach is for storing effectively boolean data.
As a use case, let's say that I have a bunch of analysts that need to know whether an IP address is in IPV4 or IPV6 format, but the regex for IPv6 format takes to long to keep rerunning so, I decided to add some pre processing step, report, si, whatever, which adds a field to specify IP format.
I think I have two options here. I could store information as a string using an "ip_format" field with values of "ipv4", "ipv6" or "invalid". Or I could create an "is_ipv4" field with either "true" or "false" string,
Or I could go the Number route and have an "is_ipv4" field with either a 0 and 1 to represent false and true.
All of this works fine, but seems cumbersome. If I go with the string approach, I risk all the dangers of "magic strings", mostly mistyping them or forgetting what they are. As a lesser issue, my later searches are a little longer to write due to the need to write a full matches syntax, and I may suffer some minor expense in doing the string comparison.
If I go with the number approach, I risk less human readable code, as someone needs to know that the 1 and 0 represent true and false, I risk bad code if someone swaps the order etc.
I'm wondering if Splunk developers recommend one of these approaches, or if they support a cleaner option I'm missing. For instance, does some approach for avoiding magic strings, even if it's just some syntactical sugar like having a predefined "true" and "false" string that functions recognize? If there is no syntactical sugar...is there a reason that there isn't syntactical sugar, such as a desire to discourage Boolean fields at all, or is that just a feature that is a nice to have, but wasn't prioritized yet?
↧