[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089094#comment-17089094
]
David Capwell commented on CASSANDRA-15234:
-------------------------------------------
Most of my experience with SnakeYaml is as a plugin to Jackson, normally
Jackson is better at converting JSON/YAML -> Object and offers more
flexibility; I may have misread you but the "int" null case isn't normally an
issue in Jackson (assuming you define defaults). If this is a real limitation,
wonder if it's better to use Jackson as the interface with SnakeYaml as the
parser?
I skimmed part 2 quickly. What I see is you offer two fields: string, and
parsed value. If the user provides the string version we attempt to parse it
and update the parsed value. In order to add a new field we would need to
define the string and parsed versions, and provide the mapping to the
MEM_UNITS_MAP map; my first thought is "why not make this a type?"
I hope this example is clear to my thinking
{code}
class Memory {
long bytes;
public Memory(String value) {
this.bytes = parse(value);
}
public long getBytes() { return bytes};
public long getKillaBytes() { return bytes * 1024 };
...
}
{code}
{code}
Memory max_value_size = Memory.ofMb(256);
{code}
I quickly prototyped this for the field I showed and it parses just fine, also
has the benefit that we drop a lot of unit conversions since config spec !=
runtime value (config is mb, runtime is bytes).
My thinking is having types rather than the primitives is easier to read,
easier to work with, easier to use with properties, etc; it also means we don't
need to maintain the mapping from string to parsed fields.
The other benefit is it plays nicely with part 1. We only have a single field,
and if the user defines the new and the old the logic for which is used is
centralized in a single place.
Ill start reading part 3 now.
> 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, 4.0-beta
>
>
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
