We can not support both the "rule" that new settings have the new format, and the design goal that the CQL statement format be accepted.
We came to a compromise. We introduced the new chunk_length parameter that requires a DataStorageSpec We reused the CQL chunk_length_in_kb parameter to accept the CQL format. I think this is a reasonable compromise. We could emphasize the chunk_length parameter in documentation changes and leave the chunk_length_in_kb parameter to a discussion of converting CQL to YAML configuration. We could put in a log message that recommends the correct chunk_length parameter based on chunk_length_in_kb value. But I do not see a way to support both requirements for the new format and the CQL format support. We can deprecate the chunk_length_in_kb as soon as CQL changes to use a DataStorageSpec for its parameter, but I do not know of any proposals to change CQL. On Tue, Mar 19, 2024 at 1:09 PM Ekaterina Dimitrova <e.dimitr...@gmail.com> wrote: > Any new settings are expected to be added in the new format > > On Tue, 19 Mar 2024 at 5:52, Bowen Song via dev <dev@cassandra.apache.org> > wrote: > >> I believe the `foobar_in_kb: 123` format in the cassandra.yaml file is >> deprecated, and the new format is `foobar: 123KiB`. Is there a need to >> introduce new settings entries with the deprecated format only to be >> removed at a later version? >> >> >> On 18/03/2024 14:39, Claude Warren, Jr via dev wrote: >> >> After much work by several people, I have pulled together the changes to >> define the default compression in the cassandra.yaml file and have created >> a pull request [1]. >> >> If you are interested this in topic, please take a look at the changes >> and give at least a cursory review. >> >> [1] https://github.com/apache/cassandra/pull/3168 >> >> Thanks, >> Claude >> >>
