Additional field validations
MarcPer opened this issue · comments
Hi.
I'm looking into adding support for a new aggregation type. While doing it, it occurred to me that it might be a good idea to validate the field values as well, according to what Druid requires. For example, the lgK field in DataSketches HLL has to be in the [4,21] range, so the setter method might check this.
What do you think? Returning an error from the setter is a breaking change, so one alternative is storing errors in the struct, that could be returned via an Error method, or something along those lines.
Hello @MarcPer
Thank you for your initiative!
Having new aggregation type is a great thing :) The library mostly support core types for now.
Indeed returning an error is a bit tricky. Doing so from the setter would not only break the backward compatibility but also kill the chaining (e.g: s1 := filter.NewSelector().SetDimension("countryName").SetValue("France") from https://github.com/grafadruid/go-druid/blob/master/examples/main.go#L44 ).
We're open to discuss it. feel free to join on slack so we can discuss more interactively!
Yeah, I totally see this would break the chaining. That's why I was suggesting an alternative.
I was thinking something along these lines: The Base struct could have an errors []error field, for instance. Then, anytime a setter is called with an invalid input, an error would be stored into this field. These error messages could later be retrieved, for example, with agg.Errors(). That way, the return type of the setters wouldn't change.
Discussed on Slack.
Implementation idea:
s1 := filter.NewSelector().SetDimension("countryName").SetValue("France")
if s1.Err != nil {
...
}
Err being a member of the filter struct
maybe having this buffer a LIFO
so you get only the latest error
otherwhise, a slice of err.
We also agreed that we can let Druid manage the validations for now, if at some point there is more demand for such early error catching we could reconsider it.
Thanks for the discussion!