Replies: 3 comments 1 reply
-
Can you please tell us what we are fixing that is "unexpected"? What did you expect? Most of the options we "correct" would be impossible to deal with, we are not really "changing" anything, mostly setting up defaults. |
Beta Was this translation helpful? Give feedback.
-
I'm working on some code to support out of order inserts into Head. instead I notice that:
I looked a bit closer at validateOpts. It checks 6 options. only 2 of them are actually user input( As someone trying to contribute to the code, and trying to follow the best practices, it seems overly complicated to have validation in so many different places, especially to validate user input so late (NewHead) in some cases, and to have a function called validate, which actually doesn't really do what its name suggests. I would also expect there to be 1 single place where defaults are set (e.g. in main, although this could call a helper function inside the tsdb package for tsdb defaults), followed by letting users override defaults, followed by validation. So TLDR: i think we can simplify and clean up this code, or at least better document validateOpts() to describe what it is for. This would make the code base more accessible to new developers. |
Beta Was this translation helpful? Give feedback.
-
Agree with simplification, and each package having their own ValidateOpts so that the validation is owned by that package. However, I would like to not error, and log the adjustments that we make. |
Beta Was this translation helpful? Give feedback.
-
why does it do this?
why don't we validate and return errors for incorrect configuration?
now we silently fix things in ways that are quite opaque to the user. they may not get the configuration they expected.
Beta Was this translation helpful? Give feedback.
All reactions