[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17148852#comment-17148852
]
David Capwell commented on CASSANDRA-15234:
-------------------------------------------
Given the framework provided by this patch, the following wouldn't be hard to
support (all, not just 1 or 2)
1) no warning or plan to remove
2) warning that it will be removed some day
3) warning on specific version which will remove
So, we could do the following
{code}
// provide a warning that this will not longer be supported after 5.0
@Replaces(oldName = "native_transport_idle_timeout_in_ms", converter =
Converter.MillisDurationConverter.class, scheduledRemoveBy = "5.0")
public volatile Duration native_transport_idle_timeout = new Duration("0ms");
// provide a warning that the property is deprecated and will be removed one day
@Replaces(oldName = "native_transport_idle_timeout_in_ms", converter =
Converter.MillisDurationConverter.class, deprecated = true)
public volatile Duration native_transport_idle_timeout = new Duration("0ms");
// no warning, both properties are fully supported
@Replaces(oldName = "native_transport_idle_timeout_in_ms", converter =
Converter.MillisDurationConverter.class)
public volatile Duration native_transport_idle_timeout = new Duration("0ms");
{code}
Given the framework makes it trivial to support old names, having no properties
marked for removal of 5.0 works for me. If we really want to migrate usage to a
new name, then mark it to be removed one day, and stuff which is personal
preference (such as enable at the start or end of the name) can have no
warning; does this make sense?
> Standardise config and JVM parameters
> -------------------------------------
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
> Reporter: Benedict Elliott Smith
> Assignee: Ekaterina Dimitrova
> Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
