[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717012#comment-17717012
]
Jacek Lewandowski edited comment on CASSANDRA-18441 at 4/27/23 7:31 AM:
------------------------------------------------------------------------
I'm sorry for going through it again, but I'd put the selected write format on
a parent level, that is, if translated into properties, it could look like this:
{noformat}
sstable.selected_format=big
sstable.format.big.max_version=nc
sstable.format.big.opt1=value1
{noformat}
The reason I don't want to do this:
{noformat}
sstable.format.default=big
sstable.format.big.write_version_limit=nc
sstable.format.big.opt1=value1
{noformat}
is that, I'd have to actually use {{Map<String, Object>}} on the
{{sstable.format}} level (at least I don't know how to do that differently)
And, since we want to have some consistency around properties, this
{{sstable.format.<which format>.<option>=<sth>}} speaks to me more than
{{sstable.format.options.<which format>.<option>=<sth>}}
In summary, selected format is not a property of any format, IMO it better fits
to sstable level.
Regarding target version and format - I agree it will be probably modified with
the downgradability ticket, thus those fields will be completely optional. I
like the idea of having Cassandra version --> format/version mapping. I've
changed the name of the write version to "max_version" so that it expresses
more adequately what that parameter means.
was (Author: jlewandowski):
I'm sorry for going through it again, but I'd put the selected write format on
a parent level, that is, if translated into properties, it could look like this:
{noformat}
sstable.selected_format=big
sstable.format.big.write_version_limit=nc
sstable.format.big.opt1=value1
{noformat}
The reason I don't want to do this:
{noformat}
sstable.format.default=big
sstable.format.big.write_version_limit=nc
sstable.format.big.opt1=value1
{noformat}
is that, I'd have to actually use {{Map<String, Object>}} on the
{{sstable.format}} level (at least I don't know how to do that differently)
And, since we want to have some consistency around properties, this
{{sstable.format.<which format>.<option>=<sth>}} speaks to me more than
{{sstable.format.options.<which format>.<option>=<sth>}}
In summary, selected format is not a property of any format, IMO it better fits
to sstable level.
Regarding target version and format - I agree it will be probably modified with
the downgradability ticket, thus those fields will be completely optional. I
like the idea of having Cassandra version --> format/version mapping. I've
changed the name of the write version to "write_version_limit" so that it
expresses more adequately what that parameter means.
> Improvements to SSTable format configuration
> --------------------------------------------
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
> Reporter: Branimir Lambov
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
