[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713571#comment-17713571
]
Stefan Miklosovic commented on CASSANDRA-12937:
-----------------------------------------------
I again do not have any clear answer why we are "extracting" something and then
we have extra parameterized class with further options.
_Currently CompressionParams takes the class name and the parameters. It
extracts chunk_length_kb (or chunk_length_in_kb) and min_compress_ratio from
the parameters and uses them to build the CompressionParams instance._
Do not you just try to copy the same approach as in "CompressionParams extracts
these parameters so we need to apply same extraction in cassandra.yaml"? Why is
the extraction like it is suggested important? Why we can not flatten the
configuration? It is quite questionable why we are having nested sections like
that when, from ux perspective, it is truly just a map. The fact that we are
doing something internally in some fashion does not mean that it has to
manifest into the configuration in cassandra.yaml.
If we want to support same values as in other places in cassandra.yaml but have
nice flat map (preferably), would not it be possible to translate these values
internally into the old values? Or even better, would it be possible to have
new value parameters in cassandra.yaml but they would be transformed internally
into the old values? The most idealistic option would be to start to support
the same format of values for parameters in cassandra.yaml in CQL as well.
I do not think that without further discussion how this should be modeled and
reaching broader consensus this ticket is close to the actual merging.
> Default setting (yaml) for SSTable compression
> ----------------------------------------------
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
> Reporter: Michael Semb Wever
> Assignee: Claude Warren
> Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
