Edit: I meant to say smaller to bigger unit, not size, sorry On Thu, 25 Apr 2024 at 6:35, Ekaterina Dimitrova <e.dimitr...@gmail.com> wrote:
> Quick comment: > > DataRateSpec, DataStorageSpec, or DurationSpec > - we intentionally do not support going smaller to bigger size in those > classes which are specific for cassandra.yaml - precision issues. Please > keep it that way. That is why the notion of min unit was added in > cassandra.yaml for parameters that are internally represented in a bigger > unit. > > I am not sure that people want to add TiB. There was explicit agreement > what units we will allow in cassandra.yaml. I suspect any new units should > be approved on the ML > > Hope this helps > > > > On Thu, 25 Apr 2024 at 5:55, Claude Warren, Jr via dev < > dev@cassandra.apache.org> wrote: > >> TiB is not yet in DataStorageSpec (perhaps we should add it). >> >> A quick review tells me that all the units are unique across the 3 >> specs. As long as we guarantee that in the future the method you propose >> should be easily expandable to the other specs. >> >> +1 to this idea. >> >> On Thu, Apr 25, 2024 at 12:26 PM Štefan Miklošovič < >> stefan.mikloso...@gmail.com> wrote: >> >>> That is a very interesting point, Claude. My so-far implementation is >>> using FileUtils.stringifyFileSize which is just dividing a value by a >>> respective divisor based on how big a value is. While this works, it will >>> prevent you from specifying what unit you want that value to be converted >>> to as well as it will prevent you from specifying what unit a value you >>> provided is of. So, for example, if a column is known to be in kibibytes >>> and we want that to be converted into gibibytes, that won't be possible >>> because that function will think that a value is in bytes. >>> >>> It would be more appropriate to have something like this: >>> >>> to_human_size(val) -> alias to FileUtils.stringifyFileSize, without any >>> source nor target unit, it will consider it to be in bytes and it will >>> convert it like in FileUtils.stringifyFileSize >>> >>> to_human_size(val, 'MiB') -> alias for to_human_size(val, 'B', 'MiB') >>> to_human_size(val, 'GiB') -> alias for to_human_size(val, 'B', 'GiB') >>> >>> the first argument is the source unit, the second argument is target unit >>> >>> to_human_size(val, 'B', 'MiB') >>> to_human_size(val, 'B', 'GiB') >>> to_human_size(val, 'KiB', 'GiB') >>> to_human_size(val, 'KiB', 'TiB') >>> >>> I think this is more flexible and we should funnel this via >>> DataStorageSpec and similar as you mentioned. >>> >>> In the future, we might also add to_human_duration which would be >>> implemented against DurationSpec so similar conversions are possible. >>> >>> On Fri, Apr 19, 2024 at 10:53 AM Claude Warren, Jr via dev < >>> dev@cassandra.apache.org> wrote: >>> >>>> I like the idea. Is the intention to have the of the function be >>>> parsable by the config parsers like DataRateSpec, DataStorageSpec, or >>>> DurationSpec? >>>> >>>> Claude >>>> >>>> On Thu, Apr 18, 2024 at 9:47 PM Ariel Weisberg <ar...@weisberg.ws> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I think it’s a good quality of life improvement, but I am someone who >>>>> believes in a rich set of built-in functions being a good thing. >>>>> >>>>> A format function is a bit more scope and kind of orthogonal. It would >>>>> still be good to have shorthand functions for things like size. >>>>> >>>>> Ariel >>>>> >>>>> On Tue, Apr 9, 2024, at 8:09 AM, Štefan Miklošovič wrote: >>>>> >>>>> Hi, >>>>> >>>>> I want to propose CASSANDRA-19546. It would be possible to convert raw >>>>> numbers to something human-friendly. >>>>> There are cases when we write just a number of bytes in our system >>>>> tables but these numbers are just hard to parse visually. Users can indeed >>>>> use this for their tables too if they find it useful. >>>>> >>>>> Also, a user can indeed write a UDF for this but I would prefer if we >>>>> had something baked in. >>>>> >>>>> Does this make sense to people? Are there any other approaches to do >>>>> this? >>>>> >>>>> https://issues.apache.org/jira/browse/CASSANDRA-19546 >>>>> https://github.com/apache/cassandra/pull/3239/files >>>>> >>>>> Regards >>>>> >>>>> >>>>>
