Agree with the proposal. Those properties go into config files (json/hocon), and it is difficult to navigate to relevant docs from there.
I would go with point 3 - longer suffixes like Millis - to make it unambiguous. On Fri, Dec 23, 2022 at 10:06 AM Roman Puchkovskiy < roman.puchkovs...@gmail.com> wrote: > Hi Igniters! > > In Ignite 3, in configuration schemas, we have some properties that > define durations/intervals (usually, these are timeout durations). > Almost always they are defined without mentioning the duration unit, > like this: > > /** Node join timeout. */ > @Value(hasDefault = true) > public int joinTimeout = 5_000; > > This makes a user puzzled about the unit of measure: it might be > milliseconds (as it often is), but who knows. > It seems beneficial to include the unit of measure in names of such > properties, like joinTimeoutMs or joinTimeoutMillis. > > We might try to solve this via documentation, but, when a property > name speaks by itself, we don't need to reach for the documentation at > all, so it still seems better to have it in a name (and, if you edit a > config file, reaching for documentation might be a bit more > time-consuming than navigating to a method javadoc in an IDE). > > We could do one of the following: > > 1. Do not change the naming schema, just improve the documentation; we > might also establish a strong convention of always having all > durations in the same unit (like milliseconds) [there is a > disadvantage: if we add a property that is naturally measured in, say, > hours, we would still have to use millis, which would make > configuration very cumbersome with all these zeros] > 2. Use short suffixes (ns/ms/sec/min/hr/days): joinTimeoutMs. There is > a problem with microseconds if we ever need them (how do we abbreviate > it according to this style?) > 3. Use longer suffixes (nanos/micros/millis/secs/mins/hours/days): > joinTimeoutMillis. A bit longer than the previous one. > 4. ... or something else? > > What do you think? >
