[
https://issues.apache.org/jira/browse/CASSANDRA-17571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526150#comment-17526150
]
Ekaterina Dimitrova edited comment on CASSANDRA-17571 at 4/22/22 1:51 AM:
--------------------------------------------------------------------------
Prototype in this [commit
|https://github.com/ekaterinadimitrova2/cassandra/commit/1ab9f32ef34402a0f74036d768a22449170052b6]
- only a few parameters were migrated for test purposes and to see how it will
look like.
Also, I will split in separate commits the parameters in groups on migration
with attached tests to them and CI to be sure gradually nothing Is missed but I
want to confirm that the approach is still what we want. CC [~adelapena] in
case he has time to provide input.
Currently if people provide the new config with the new format we handle the
former int parameters by returning cast value from their getters, but on
startup the user might set a bigger long value and think wrongly that one will
be used when in practice the Integer.MAX_VALUE will be used. We need just to
fail the user they can't set that big value, mimic the behavior of when they
provide old value bigger than int. We also limit with these classes that people
cannot set anything that will overflow during conversion to the smallest
allowed unit instead of setting MAX_VALUE silently.
was (Author: e.dimitrova):
Prototype in this [commit
|https://github.com/ekaterinadimitrova2/cassandra/commit/1ab9f32ef34402a0f74036d768a22449170052b6]
- only a few parameters were migrated for test purposes and to see how it will
look like.
Also, I will split in separate commits the parameters in groups on migration
with attached tests to them and CI to be sure gradually nothing Is missed but I
want to confirm that the approach is still what we want. CC [~adelapena] in
case he has time to provide input.
Currently if people provide the new config with the new format we handle the
former int parameters by returning cast value from their getters, but on
startup the user might set a bigger long value and think wrongly that one will
be used when in practice the Integer.MAX_VALUE will be used. We need just to
fail the user they can't set that big value, mimic the behavior of when they
provide old value bigger than int. We also limit with these classes that people
cannot set anything that will overflow during conversion to the smallest
allowed unit instead of setting MAX_VALUE silently.
> Config upper bound should be handled earlier
> --------------------------------------------
>
> Key: CASSANDRA-17571
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17571
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
> Reporter: Ekaterina Dimitrova
> Assignee: Ekaterina Dimitrova
> Priority: Normal
> Fix For: 4.1
>
>
> Config upper bound should be handled on startup/config setup and not during
> conversion
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
